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! 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. > what's the interface to NSPR_LOG_MODULES? still with the numerics, or > do we have to use > NSPR_LOG_MODULES=signaling:debug,mediamanager:debug,getusermedia:debug,mtransport:debug,mediastreamgraph:debug > etc? (That gets a bit old... not that numerics are "better", but > they're faster to type/read and lots of existing scripts/etc have them.) > Obviously one could have numbers and names. Initially I plan to keep the same format for compatibility, eventually I would like to move away from it (or provide an improved method of setting log levels). [1] https://hg.mozilla.org/mozilla-central/annotate/3e737d30f842/nsprpub/pr/include/prlog.h#l166 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
