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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Apr 15 2003 - 22:00:34 EST