From: Greg KH <greg@kroah.com>
To: Dominik Brodowski <linux@dominikbrodowski.net>,
Jason Baron <jbaron@redhat.com>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
joe@perches.com, nick@nick-andrew.net, randy.dunlap@oracle.com
Subject: Re: [PATCH 1/7] dynamic debug v2 - infrastructure
Date: Thu, 17 Jul 2008 16:35:24 -0700 [thread overview]
Message-ID: <20080717233524.GA28711@kroah.com> (raw)
In-Reply-To: <20080717225611.GA27481@isilmar.linta.de>
On Fri, Jul 18, 2008 at 12:56:11AM +0200, Dominik Brodowski wrote:
> Hi,
>
> On Thu, Jul 17, 2008 at 03:32:22PM -0700, Greg KH wrote:
> > > that is correct. any callers of dev_dbg() don't have to do anything. its really
> > > only the more complex debugging, where there are flags or levels that need to
> > > make adjustments to work with the new infrastructure.
> >
> > For this reason alone, I see no reason why your patch should not be
> > merged today. You don't need the other subsystems at this point in time
> > in my opinion, it's benifit is huge already.
>
> not to object to this statement, but:
>
> what about the user-visible interface? currently, it's based around one big
> debugfs file. What about doing
>
> <debugfs>/dynamic_printk/<module_name>/{enabled[,level][,flag][,modules]}
By virtue of this being in debugfs, we can change the user interface
around as time goes on if we want to with no ill side affects. :)
> instead, or even
>
> <sysfs>/module/<module_name>/debug/{enabled[,level][,flag]}
I like this as that is what a number of current modules do (usb-serial
drivers), but you have to be careful about the module parameter
namespace to not get collisions here with existing "debug" files.
So for now, I recommend staying in debugfs, it makes more sense.
thanks,
greg k-h
next prev parent reply other threads:[~2008-07-17 23:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 21:31 [PATCH 1/7] dynamic debug v2 - infrastructure Jason Baron
2008-07-17 7:01 ` Greg KH
2008-07-17 21:20 ` Jason Baron
2008-07-17 22:32 ` Greg KH
2008-07-17 22:56 ` Dominik Brodowski
2008-07-17 23:35 ` Greg KH [this message]
2008-07-18 6:37 ` Dominik Brodowski
2008-07-18 14:39 ` Jason Baron
2008-08-08 21:51 ` Jason Baron
2008-08-09 1:07 ` Greg KH
2008-08-11 14:12 ` Jason Baron
2008-08-11 16:45 ` Greg KH
2008-08-09 2:38 ` Randy Dunlap
2008-08-11 17:36 ` Jason Baron
2008-08-11 22:33 ` Greg KH
2008-08-12 19:48 ` Jason Baron
2008-08-12 20:09 ` Greg KH
2008-08-12 20:46 ` Jason Baron
2008-08-13 1:08 ` Greg KH
2008-08-13 1:16 ` Andrew Morton
2008-08-13 3:38 ` Greg KH
2008-08-13 20:00 ` Sam Ravnborg
2008-08-13 22:49 ` jbaron
2008-08-13 23:54 ` Greg KH
2008-08-14 1:25 ` Greg KH
2008-08-13 19:05 ` Jason Baron
2008-08-14 14:53 ` Greg KH
2008-08-14 21:05 ` Jason Baron
2008-09-16 0:03 ` Rusty Russell
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=20080717233524.GA28711@kroah.com \
--to=greg@kroah.com \
--cc=akpm@linux-foundation.org \
--cc=jbaron@redhat.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=nick@nick-andrew.net \
--cc=randy.dunlap@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.