search

PelionIoT / mbed-trace

mbed trace library
Apache License 2.0
18 stars 15 forks source link

Is there a way to suppress messages from specific libraries? #76

Open mbanders opened 7 years ago

mbanders commented 7 years ago

Some libraries are excessively verbose with mbed trace messages. It slows down and frustrates developers/testers while they try to keep an eye out for the messages from the functions they actually care about.

Is there a way to supress messages from specific libraries or functions? Or is mbed trace an "all or nothing" type of thing? You get all messages, or none of them.

ciarmcom commented 7 years ago

ARM Internal Ref: IOTSYST-2492

tommikas commented 7 years ago

There isn't currently a compile time method for doing this. At runtime you can control which trace groups are visible with the exclude and include filters. Basically these work by scanning the defined filter string for the substring \<trace group> for each mbed_tracef call.

Would that help at all?

jupe commented 6 years ago

@kjbracey-arm do you have some good ideas how we could do compile time solution to disable/enable traces by individual group/file with minimal affects to existing API's and source codes, which also works seamless with all compilers and OS's we support.. ?

kjbracey commented 6 years ago

I think you could do something if the groups could be specified as tokens - MyLb rather than "MyLb".

You would use the # operator to stringise these before passing to the formatter, and could use token pasting with ## to look for MBED_TRACE_GROUP_xxxx_ENABLE or DISABLE or something.

And then I guess a legacy fallback for what to do with existing "string" groups.

Final thought - as per Linux, you might want to treat "debug" distinctly - that has a "dynamic debug" feature which does this sort of per file/module/function filtering, but that is specific to "debug" level, which is the thing thought to be verbose enough to want the facility. Higher things are not filterable in that way. So maybe such compile-time switching (and maybe the runtime filtering) should/could be debug-specific, or optionally so.