From: Martin Hicks <mort@wildopensource.com>
To: Daniel Stekloff <dsteklof@us.ibm.com>
Cc: Martin Hicks <mort@wildopensource.com>,
Patrick Mochel <mochel@osdl.org>,
"Randy.Dunlap" <rddunlap@osdl.org>,
hpa@zytor.com, pavel@ucw.cz, jes@wildopensource.com,
linux-kernel@vger.kernel.org, wildos@sgi.com
Subject: Re: [patch] printk subsystems
Date: Thu, 17 Apr 2003 11:56:04 -0400 [thread overview]
Message-ID: <20030417155604.GC543@bork.org> (raw)
In-Reply-To: <200304161243.58291.dsteklof@us.ibm.com>
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. mort@wildopensource.com
next prev parent reply other threads:[~2003-04-17 15:44 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
2003-04-17 15:56 ` Martin Hicks [this message]
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=20030417155604.GC543@bork.org \
--to=mort@wildopensource.com \
--cc=dsteklof@us.ibm.com \
--cc=hpa@zytor.com \
--cc=jes@wildopensource.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.org \
--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).