On Tue, Jun 9, 2020 at 4:23 PM Joe Perches <joe@xxxxxxxxxxx> wrote: > > On Tue, 2020-06-09 at 15:21 -0600, jim.cromie@xxxxxxxxx wrote: > > > > As Joe noted, there is a lot of ad-hockery to possibly clean up, > > but I dont grok how these levels should be distinguished from > > KERN_(WARN|INFO|DEBUG) constants. > > These are not KERN_<LEVEL> at all, all are emitted at KERN_DEBUG yes indeed. but they are chosen by programmer, fixed by compiler. not dynamic. <pmladek@xxxxxxxx> also noted the conceptual adjacency (ambiguity), and referenced KERN_<lvl> If we need this extra query-term, lets call it mbits / mflags / module_flags / module_bits it needs to be module specific, so also requiring "module foo" search term in the query. ( "modflags" is no good, cuz "mod" also means "modified" - just mflags is better ) Already, we have function, file, module, all of which convey semantic structure of the code, and they also match wildcards, so " function foo_*_* " is an effective grouping. Id think this would cover most cases. Finally, all "module venus +p " callsites could be explicitly specified individually in universe=`grep venus control | wc -l` lines, likely a small set. Using the semantic structure exposed by `grep venus control`, it would likely be far less.
