[Webkit-unassigned] [Bug 241719] New: Enhance Options::useOSLog to accept an os log type value.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=241719

            Bug ID: 241719
           Summary: Enhance Options::useOSLog to accept an os log type
                    value.
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mark.lam at apple.com

This option only applies to OS(DARWIN).

For example, we can now use any of these:
    --useOSLog=default    // logs to OS_LOG_TYPE_DEFAULT
    --useOSLog=info       // logs to OS_LOG_TYPE_INFO
    --useOSLog=debug      // logs to OS_LOG_TYPE_DEBUG
    --useOSLog=error      // logs to OS_LOG_TYPE_ERROR
    --useOSLog=fault.     // logs to OS_LOG_TYPE_FAULT

We can still use --useOSLog=0 or false (which means do the normal dataLog) and --useOSLog=1 or true (which means dataLog to OS_LOG_TYPE_ERROR).

Previously, when we specify --useOSLog=1, we will data log to OS_LOG_TYPE_INFO.  This has been a source of friction in usage because no one ever remembers that we need enable OS_LOG_TYPE_INFO in the log stream  to see this logging.  Instead, --useOSLog=1 will now log to OS_LOG_TYPE_ERROR, which ensures that logging will show up in log stream.  This is fine to do because the --useOSLog=1 option indicates that the client really wants to see the logs.  Otherwise, the client can use one of the other os log types if they want something different.

Secondly, because -useOSLog=1 indicates that the client really wants to see the logs, logging to OS_LOG_TYPE_ERROR ensures that the logging is flushed to the file system instead of sitting in a memory buffer, and potentially not showing up in the log stream.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220617/66fc0e64/attachment.htm>