Re: [patch] printk subsystems

[Daniel Stekloff]

On Monday 14 April 2003 11:33 am, Patrick Mochel wrote:
> > I don't like the #define DEBUG approach.  It's useless for users; it's a
> > developer debug tool.  It won't allow some support staff to ask users to
> > enable module debugging (or subsystem debugging) and see what gets
> > printed.
>
> Agreed. Having a runtime-tweakable field would be very handy, and
> something that's been requested many times over.
>
> > Martin, you are ahead of my schedule, but I was planning to use sysfs
> > to add a 'debug' flag/file that could be dynamically altered on a
> > per-module basis.
>
> Something I've pondered in the past is a per-subsystem (as in struct
> subsystem) debug field and log buffer. When the subsystem is registered, a
> sysfs 'debug' file is created, from which the user can set the noisiness
> level.

Would the debug level be for the entire subsystem? Do you think people would 
like to be able to set debug/logging level per driver or device, and not just 
subsystem? 

Is debugging level here the same as logging level? 

I like the idea of having logging levels, which include debug, defined by 
subsystem. Each subsystem will have separate requirements for logging. 
Networking, for instance, already has the NETIF_MSG* levels defined in 
netdevice.h that can be set with Ethtool. I can see, for example, having the 
msg_enable not in the private data as it is now but in the subsystem or class 
structure for that device, such as in struct net_device. This could easily be 
exported through sysfs. 

Thanks,

Dan

> From there, each subsystem can specify the size of a log buffer, which
> would be allocated also when the subsystem is registered. Messages from
> the subsystem, and kobjects belonging to it, would be copied into the
> local log buffer.
>
> Wrapper functions can be created, similar to the dev_* functions, which
> take a kobject as the first parameter. From this, the subsystem and log
> buffer, can be derived (or rather, passed to a lower-level helper).
>
> This all falls under the 'gee-whiz-this-might-be-neat' category, and may
> inherently suck; I haven't tried it. Doing the core code is < 1 day's
> work, though there would be nothing that actually used it..
>
>
> 	-pat