From: Tilman Schmidt <tilman@imap.cc>
To: kernel-janitors@vger.kernel.org
Subject: [KJ] Re: [PATCH] usb.h: reduce syslog clutter
Date: Tue, 21 Mar 2006 00:56:37 +0000 [thread overview]
Message-ID: <441F4F45.4000801@imap.cc> (raw)
In-Reply-To: <20060320194109.GA16890@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 2953 bytes --]
On 20.03.2006 21:39, Greg KH wrote:
> On Mon, Mar 20, 2006 at 09:00:11PM +0100, Tilman Schmidt wrote:
>
>>On 20.03.2006 20:41, Greg KH wrote:
>>
>>
>>>On Sat, Mar 18, 2006 at 08:53:26PM +0100, Tilman Schmidt wrote:
>>>
>>>
>>>>The current versions of the err() / info() / warn() message macros in
>>>>include/linux/usb.h insert __FILE__ at the beginning of the message.
>>>>[...]
>>>>The following patch modifies these macros so that, when used in a
>>>>module, they'll insert the module name instead, which is significantly
>>>>shorter and also tends to be more useful to users (as opposed to kernel
>>>>developers) trying to make sense of a particular message.
>>>>
>>>>It also adds a macro for the "notice" message level which was missing
>>>>so far.
>>>
>>>[...]
>>>What was wrong with my suggestion that we simply delete these macros and
>>>convert the USB code over to using the proper dev_info(), dev_warn(),
>>>dev_err(), and dev_notice() macros instead?
>>
>>Just that, as you remarked yourself:
>>
>>
>>>[T]here are a few places in the USB code that do
>>>not have a valid device and so they can't be dropped entirely.
>>
>>and I still don't see how to handle that situation with the dev_ macros.
>>
>>But I thought you said you would accept that patch if I submitted it
>>through the kernel-janitors. Why the change of mind?
>
> No, I think you misunderstood me. I said that converting the USB code
> over to using the proper dev_* macros would be a good janitor's project,
> not that you need to submit this patch through them.
>
> There are only a very few places that these macros can not be used, and
> only after converting everything that can possibly be changed, then we
> can see if these are still really needed or not.
Greg, as you may remember, Hansjörg and I are trying to submit an
existing, working driver for inclusion in the main kernel tree. That
driver does have quite a few places where it must emit a message without
reliably having access to a valid device structure. The janitors can't
convert that for us because it is not part of the tree yet; it can't
become part of the tree because it uses those macros you say shouldn't
be propagated any further; I can't convert it myself because I don't
know how, and when I ask you you only tell me not to worry. Catch-22.
What harm does it do to fix those macros now when they are needed in
existing code, even if they might disappear sometime in kernel 2.6.21 or
so? Does it justify blocking the inclusion of a driver in the tree?
Fourteen months ago you told me there were no valid reasons for not
including a USB driver in the main kernel tree. Have we hit upon such a
reason after all?
Regards
Tilman
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
next prev parent reply other threads:[~2006-03-21 0:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-20 19:41 [KJ] Re: [PATCH] usb.h: reduce syslog clutter Greg KH
2006-03-20 20:00 ` Tilman Schmidt
2006-03-20 20:39 ` Greg KH
2006-03-21 0:56 ` Tilman Schmidt [this message]
2006-03-22 20:56 ` Greg KH
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=441F4F45.4000801@imap.cc \
--to=tilman@imap.cc \
--cc=kernel-janitors@vger.kernel.org \
/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.