[lkml]   [2012]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[00/11] pr_debug during module initialization

This is 3rd revision of the dyndbg modinit patches, previously sent
Dec 11. Patches 1-17/25 sent then were added to driver-core-next,
this set reworks the remainder.

It implements the "fake" module param approach proposed by
Thomas Renninger, back in

This set is on top of linux-next, since that includes Pawel Moll's
initcall-level params patch. Im not using this feature, but I didnt
know that when I started.

Rusty Russell did a partial review of 2nd rev (sent off-list), here:
This revision incorporates my understanding of his feedback.

Core of patchset is 2 callbacks, called from parse_args:

For builtin modules, dynamic_debug_init() calls parse_args(...,
&ddebug_dyndbg_boot_param_cb) to handle dyndbg and $module.dyndbg
params. For loadable modules, load_module() calls parse_args(...,
&ddebug_dyndbg_module_param_cb) to handle dyndbg args given by
modprobe. Both callbacks call ddebug_exec_queries() to activate the
specified pr_debug callsites.

This adds pr_info for each initcall-level, yielding 7 lines in dmesg
initlevel:6=device, 172 registered initcalls

I dropped the pr_debug added in 2nd rev, which was noisy and not
useful, init_debug provides similar info and more. This patch is
decoration only, and can be dropped.


I should have done this previously. Ive disregarded a complaint about
wrapping complex macro args in (), since theres plenty of similar code
in include/*

Change "ddebug_query" to "dyndbg", to match new $module.dyndbg added
by this patchset.

Current message doesnt ID the param name being handled.

Add "doing" to lower levels of param handling callchain, supplying it
to callback added next.

main patch of set.

Adjust pnp for CONFIG_PNP_DEBUG_MESSAGES. Unchanged since Dec 11th

This allows parsing $modname.dyndbg=" func foo +p ; func bar +p"
without repeating "module $modname" 2x in the value

This gets a checkpatch complaint because of long lines in which I
tweaked flags. I chose to disregard this cuz the lines show real
output for ~out-of-tree code.

This works-for-me, but may be broken on some arches I dont have to
test on. I dont know why original design used arch_initcall, perhaps
constraints have changed. I also tested with early_initcall, that
also worked.

 \ /
  Last update: 2012-03-15 00:05    [W:0.080 / U:8.824 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site