From: Daniel Stekloff <dsteklof@us.ibm.com>
To: Patrick Mochel <mochel@osdl.org>, "Randy.Dunlap" <rddunlap@osdl.org>
Cc: 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: Mon, 14 Apr 2003 15:33:18 -0700 [thread overview]
Message-ID: <200304141533.18779.dsteklof@us.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0304141325010.14087-100000@cherise>
On Monday 14 April 2003 11:33 am, 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.
Would the debug level be for the entire subsystem? Do you think people would
like to be able to set debug/logging level per driver or device, and not just
subsystem?
Is debugging level here the same as logging level?
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.
Thanks,
Dan
> 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..
>
>
> -pat
next prev parent reply other threads:[~2003-04-14 22:22 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 [this message]
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
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=200304141533.18779.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).