Messages in this thread | | | From | jim.cromie@gmail ... | Date | Tue, 9 Jun 2020 21:10:15 -0600 | Subject | Re: [PATCH v3 0/7] Venus dynamic debug |
| |
On Tue, Jun 9, 2020 at 4:23 PM Joe Perches <joe@perches.com> wrote: > > On Tue, 2020-06-09 at 15:21 -0600, jim.cromie@gmail.com 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@suse.com> 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.
| |