[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201009271025.47558.trenn@suse.de>
Date: Mon, 27 Sep 2010 10:25:46 +0200
From: Thomas Renninger <trenn@...e.de>
To: Bjorn Helgaas <bjorn.helgaas@...com>
Cc: gregkh@...e.de, linux-kernel@...r.kernel.org, jbaron@...hat.com
Subject: Re: Dynamic Debug module.ddebug fake param enhancements V4
On Friday 24 September 2010 16:56:16 Bjorn Helgaas wrote:
> On Friday, September 24, 2010 06:28:27 am Thomas Renninger wrote:
> > The patches are intended for Greg's tree and depend on 3 other
> > dynamic debug patches which already are in linux-next, but not in
> > the vanilla kernel yet.
> >
> > [PATCH 1/4] Dynamic Debug: Introduce global fake module param module.ddebug - V4
> > V3 -> V4: Do not put that large arrays on the stack, make one func __init
> >
> > [PATCH 2/4] PNP: Compile all pnp built-in stuff in one module namespace
> > [PATCH 3/4] PNP: Use dev_dbg instead of dev_printk(KERN_DEBUG.. if DYNAMIC_DEBUG is compiled in
> > -> Compile PNP subsystem in a separate pnp module namespace
> >
> > [PATCH 4/4] kernel/module.c: Fix compiler warnings if debug is compiled in
> > -> minor compile fixup
> >
> > Only the two PNP patches really belong together.
> > If someone e.g. complains about the PNP patches, please still submit the rest.
>
> I confess that I don't understand the objective here (only because
> I haven't taken enough time to read and understand the patches).
>
> Some examples of how you expect to use this would probably help me
> understand. And if you can compare that with the current, more
> difficult way, that would be even better.
Yep:
Currently you do have to compile in PNP_DEBUG (or similar) to get
some interesting resource debug messages.
>
> I don't know if it's relevant, but I plan to change some of the
> pnp_dbg() uses to dev_printk(KERN_DEBUG).
That would mess up dynamic debug with these messages.
Both, dev_dbg and dev_printk(KERN_DEBUG..) has advantages and disadvantages.
Below some background about dev_dbg combined with CONFIG_DYNAMIC_DEBUG.
> Specifically, mainline
> already logs all PCI device BARs with KERN_DEBUG, so that information
> is always in dmesg. PNP currently uses pnp_dbg() for the corresponding
> ACPI device resource usage, so to get that information, I often have
> to request another boot with CONFIG_PNP_DEBUG_MESSAGES=y and "pnp.debug".
Yep, the idea is that this is not necessary anymore.
But dynamic debug has an advantage compared to printk(KERN_DEBUG..
You can explicitly define which module or even which file you want to enable
the debug messages (with this patch(es) the whole pnp
code would be compiled into one built-in module namespace).
E.g. pnp.ddebug boot param would enable all dev_dbg and pr_debug messages in:
driver/pnp/* -r
One disadvantage: this doesn't really work with (all) pci code, because
some of the PCI initialization is a way too early for ddebug (e.g. early quirks).
> I want to convert those resource messages to dev_printk(KERN_DEBUG) so
> they're just always in dmesg.
I hit the same, e.g. with pnp and driver/acpi/ec.c, there are some
dev_dbg in there... with dynamic debug you can enable ec.c debug messages by:
acpi.ddebug
(because nearly all in drivers/acpi/* -r is compiled into a global acpi
module namespace, I got the idea for pnp- Makefile prefix from there).
Or you can even specify the file:
ddebug_query="file drivers/acpi/ec.c +p"
or
ddebug_query="file ec.c +p" (afaik works as well)
all other dev_dbg and pr_debug messages stay hidden.
SLE11-SP1 already has DYNAMIC_DEBUG enabled
More info:
Documentation/dynamic-debug-howto.txt
If you take a kernel from here:
ftp://ftp.suse.com/pub/projects/kernel/kotd/master
I added my patches there for some testing now.
There the additional boot params query_ddebug="" and
module.ddebug are described in the source package, in:
Documentation/dynamic-debug-howto.txt
You can simply run a:
pnp.ddebug
to see quite some pnp output without CONFIG_PNP_DEBUG_MESSAGES
defined.
What do you think (dev_dbg vs printk(KERN_DEBUG...)?
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists