Re: [patch] printk subsystems

[Martin Hicks]

On Wed, Apr 16, 2003 at 12:43:58PM +0000, Daniel Stekloff wrote:
> On Wednesday 16 April 2003 07:16 pm, Martin Hicks wrote:
> > On Wed, Apr 16, 2003 at 11:42:59AM -0700, Patrick Mochel wrote:
> > > > 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.
> > >
> > > It would be nice. Unfortunately, it's only a nifty pipe-dream at the
> > > moment, unless some lucky volunteer would like to step forward. ;)
> >
> > I guess my question is this:
> >
> > Is the patch I posted useful enough to go into the kernel?  I think it
> > is.  It introduces very little overhead, and provides most of the
> > functionality that you guys are discussing.  It does use sysctl, and not
> > sysfs but does that really matter?
> 
> 
> I would rather not see the filtering applied to printk specifically like 
> you've done it. I think this is still another stop gap measure for buffer 
> overruns. I would like to see for:
> 
> 1) Buffer overruns - a mechanism that wouldn't hit a buffer overrun, say a 
> relayfs implementation of printk that could be easily configured in, or a 
> mechanism that knows/reports when a overrun has happened like the Linux event 
> logging project.

I don't think relayfs solves the problem either.  This just adds an
extra dependency for yet another pseudo-filesystem.  printk is something
that needs to "just work" even if the kernel is in the midst of
crashing.  Adding the extra complexity of all printk going out through a
filesystem/buffer layer is not desirable, IMHO.

It seems that the relayfs solution for buffer overflows in the printk 
buffer is to just make lots of buffers.  I really want to be able to
turn off prink logging for stuff I don't care about, without the
complexity of having fifteen different logs to look in and changing 
how get get log info from the kernel to syslog.

> 
> 2) Message filtering - a mechanism above printk that allows filtering on the 
> fly and built into the new device model. Such a mechanism as Patrick 
> described that could be put into the dev_* macros in device.h. 

I haven't looked into these features too much.  Is every piece of
hardware in a machine considered a device?
i.e., can messages from CPU probing, Memory, NUMA nodes, etc. be
filtered separately while changing the logging level on these devices at
runtime?

The dev_* printk macros are all, of course, resolved at runtime.  How
does one control these printk's at runtime?

mh

-- 
Wild Open Source Inc.                  [e-mail]