>Thanks Randell, these are good points. I'll address a few of your comments >that have not already been covered in the rest of the conversation. > >> This is used extensively in WebRTC and related media bits to enable >> *huge* amounts of debugs (like every-frame debugs for audio or video or >> per-network-packet debugs, which will swamp a system normally), and since >> people are used to enabling "debug" on random modules (or all:5), having >> verbose debugs in the "normal" :5 setting will cause pain. >> > >Here lies half the problem, that number does not mean what we were led to >think it means. Using :5 would include PR_LOG_DEBUG + 1 [1]. > >> The above will also be surprising since it will work "differently" than >> other modules, making the same sorts of debugs appear at different >> levels. This would be expecially confusing to people not frequently >> working in the module or when external users are asked to turn on >> debugging. > >This assumes log levels have been used consistently across modules, I can >assure you that is not the case :) I hope that we can get to a more >consistent state of course!
Sure - but having "debug" logs at DEBUG in module A, and INFO in module B (with "verbose-you-only-want-them-if-you-want-insane-data" being at DEBUG in B) will cause confusion. It means "turn on logging for X" requires knowledge of which of two patterns X follows. It also means all:4 (or all:debug) will cause suprising (and useless) results. And when coding, it'll be easy to use the "wrong" pattern when switching between modules. I see serious pain in a two-model system. And we have real *need* for logging at a makes-the-browser-almost-unusable volume to track down certain sorts of things. Even splitting say mediamanager:5 into mediamanager:4 (or :debug) and mediamanager_verbose:4 (or :debug) will have the same problem for all:. And it will make getting verbose logging more painful for no real reason. >I don't think it will be any more confusing when telling the external user >what level to turn on (it's already rather confusing). Do we need super >spammy? Turn on debug. Do we need just the basics? Turn on info. > >> Then there's an oddball: webrtc.org "Trace" logging (a separate >> subsystem with low-overhead buffered-IO circular-log maxed at 10MB), >> which requires a 16-bit mask. Currently this is exposed as >> webrtc_trace:65535 (for example), with a separate env var telling it >> where to put the logfile (or 'nspr' to revector the logs through NSPR >> logging, which *really* will cause problems with realtime code but is >> handy at times). For this oddball, we could do other things like move >> it to a separate env var (which is annoying to people using it, but not >> horribly). > >I think it's probably best to keep this a separate env rather than trying to >shoehorn it in. Understandable - but I've been trying to move in the opposite direction; avoiding N different env vars (and also, if I can avoid that, I have a better chance of leveraging on-the-fly log level changes without having to reinvent the wheel). -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
