From: Vladimir Kondratiev <vladimir.kondratiev@intel.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, Nick Craig-Wood <ncw@axis.demon.co.uk>
Subject: Re: __FUNCTION__ - patch for USB
Date: Fri, 11 Jan 2002 14:23:37 +0200 [thread overview]
Message-ID: <3C3ED949.4030604@intel.com> (raw)
In-Reply-To: <3C3CC04D.2080807@intel.com> <20020109222657.GA23143@kroah.com> <3C3D7289.9000302@intel.com> <20020110160927.GA26783@kroah.com>
Greg KH wrote:
>You still are changing a few dbg() macros that you don't have to change.
>
Guilty. Goal was to force some common style. There are mix of function
call styles like f() and f (). I suppose f() (without space between
function name and parenthes) is better, but it is of course religious
issue and have no 'proper' solution.
>
>Also, info(), warn() and err() should not have __FUNCTION__ added to
>them. Have you tried running the usb code with this patch? The USB
>group gets enough grief about all of the kernel log messages that we
>spit out. We do not need to see the function name for every message we
>write (the user does not need it.)
>
Questionable. There are lots of calls that used to have __FUNCTION__,
ex. 1-st chunks from patch are:
--- linux-2.4.18-pre2.orig/drivers/usb/CDCEther.c Fri Dec 21
19:41:55 2001
+++ linux-2.4.18-pre2.patched/drivers/usb/CDCEther.c Thu Jan 10
10:28:21 2002
- warn( __FUNCTION__ " failed submint rx_urb %d", res);
+ warn("failed submint rx_urb %d", res);
- err( "write_bulk_callback: device not running" );
+ err( "device not running" );
It is hard to be both flexible and easy. I suppose always have function
name in the log is a good idea. Maybe, I would even add line number.
Anyway, original macros used to add __FILE__ prefix. All these stuff
goes to syslog, and user usually do not see it at all. If one wants to
browse /var/log/messages, he is supposed to understand a little what he
going to see, and function names may help.
In places where great flexibility is required, I'd propose to keep using
printk().
>
>I think I'll wait for the debug level messages cleanup in the 2.5 USB
>code to make this kind of change (as talked about in a previous
>message.)
>
>thanks,
>
>greg k-h
>
What about macros for simple one line messages for generic usage? Any
thoughts?
I propose the following messages format:
<module>:<file>:<line>:<function> - <message_text>
Corresponded macro would be, for example:
#ifdef MODULE
#define err(format, arg...) printk(KERN_ERR "%s:%s:%d:%s - " format "\n"
,THIS_MODULE->name ,__FILE__, __LINE__, __FUNCTION__, ## arg)
#else
#define err(format, arg...) printk(KERN_ERR "%s:%d:%s - " format "\n" ,
__FILE__, __LINE__, __FUNCTION__, ## arg)
#endif
next prev parent reply other threads:[~2002-01-11 12:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-09 22:12 __FUNCTION__ - patch for USB Vladimir Kondratiev
2002-01-09 22:26 ` Greg KH
2002-01-10 10:52 ` Vladimir Kondratiev
2002-01-10 16:09 ` Greg KH
2002-01-11 12:23 ` Vladimir Kondratiev [this message]
2002-01-10 9:08 ` Nick Craig-Wood
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=3C3ED949.4030604@intel.com \
--to=vladimir.kondratiev@intel.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ncw@axis.demon.co.uk \
/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.