lkml.org 
[lkml]   [2003]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch] printk subsystems
Date
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.

For relayfs, please see: http://www.opersys.com/relayfs/index.html
For event logging, please see: http://evlog.sourceforge.net/

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.

Thanks,

Dan



> mh

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.108 / U:0.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site