public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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




  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox