From: Daniel Stekloff <dsteklof@us.ibm.com>
To: Martin Hicks <mort@wildopensource.com>, Patrick Mochel <mochel@osdl.org>
Cc: "Randy.Dunlap" <rddunlap@osdl.org>,
Martin Hicks <mort@wildopensource.com>,
hpa@zytor.com, pavel@ucw.cz, jes@wildopensource.com,
linux-kernel@vger.kernel.org, wildos@sgi.com
Subject: Re: [patch] printk subsystems
Date: Wed, 16 Apr 2003 12:43:58 +0000 [thread overview]
Message-ID: <200304161243.58291.dsteklof@us.ibm.com> (raw)
In-Reply-To: <20030416191619.GA3413@bork.org>
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
next prev parent reply other threads:[~2003-04-16 19:33 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-07 20:13 [patch] printk subsystems Martin Hicks
2003-04-08 18:41 ` Pavel Machek
2003-04-08 20:02 ` Jes Sorensen
2003-04-08 21:02 ` Pavel Machek
2003-04-08 21:10 ` H. Peter Anvin
2003-04-08 21:57 ` Pavel Machek
2003-04-08 22:02 ` Jes Sorensen
2003-04-08 22:05 ` H. Peter Anvin
2003-04-08 22:55 ` Martin Hicks
2003-04-08 23:10 ` Randy.Dunlap
2003-04-14 18:33 ` Patrick Mochel
2003-04-14 22:33 ` Daniel Stekloff
2003-04-16 18:42 ` Patrick Mochel
2003-04-16 12:35 ` Daniel Stekloff
2003-04-16 19:16 ` Martin Hicks
2003-04-16 12:43 ` Daniel Stekloff [this message]
2003-04-17 15:56 ` Martin Hicks
2003-04-17 13:58 ` Karim Yaghmour
2003-04-15 13:27 ` Martin Hicks
2003-04-15 14:40 ` Karim Yaghmour
2003-04-08 22:00 ` Jes Sorensen
2003-04-11 19:21 ` Martin Hicks
2003-04-08 23:15 Chuck Ebbert
2003-04-17 19:58 Perez-Gonzalez, Inaky
2003-04-17 20:34 ` Karim Yaghmour
2003-04-17 21:03 ` Perez-Gonzalez, Inaky
2003-04-17 21:37 ` Tom Zanussi
2003-04-18 7:21 ` Tom Zanussi
2003-04-18 7:42 ` Greg KH
2003-04-21 15:56 ` Karim Yaghmour
2003-04-21 18:23 Perez-Gonzalez, Inaky
2003-04-21 18:30 ` H. Peter Anvin
2003-04-21 18:42 Perez-Gonzalez, Inaky
2003-04-22 2:49 Perez-Gonzalez, Inaky
2003-04-22 4:34 ` Karim Yaghmour
2003-04-22 3:04 Perez-Gonzalez, Inaky
2003-04-22 6:00 ` Tom Zanussi
2003-04-22 4:02 Perez-Gonzalez, Inaky
2003-04-22 5:52 ` Karim Yaghmour
2003-04-22 6:04 ` Tom Zanussi
2003-04-22 5:09 Perez-Gonzalez, Inaky
2003-04-24 18:22 ` bob
2003-04-22 18:46 Perez-Gonzalez, Inaky
2003-04-22 23:28 ` Karim Yaghmour
2003-04-22 19:02 Perez-Gonzalez, Inaky
2003-04-22 19:03 ` H. Peter Anvin
2003-04-22 21:52 ` Tom Zanussi
2003-04-22 22:53 Perez-Gonzalez, Inaky
2003-04-23 3:58 ` Tom Zanussi
2003-04-23 0:28 Perez-Gonzalez, Inaky
2003-04-24 18:56 Manfred Spraul
2003-04-24 19:10 ` bob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200304161243.58291.dsteklof@us.ibm.com \
--to=dsteklof@us.ibm.com \
--cc=hpa@zytor.com \
--cc=jes@wildopensource.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.org \
--cc=mort@wildopensource.com \
--cc=pavel@ucw.cz \
--cc=rddunlap@osdl.org \
--cc=wildos@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).