Re: [patch] printk subsystems

[Martin Hicks <mort@wildopensource.com>]

On Mon, Apr 14, 2003 at 01:33:54PM -0500, 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. 
> 
> >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..

I'm not sure that this addresses the core problem that I'm trying to
deal with.  The problem is that machines with certain configurations
(large number of CPUs, Nodes, or a bunch of SCSI and disks) display far
too many messages to the console, resulting in the log buffer being
overflowed.  The method that I'm proposing simply allows you to decide
what gets logged when a printk() happens, depending on the message's
priority and which subsystem it originated from.

mh

-- 
Wild Open Source Inc.                  mort@wildopensource.com