All of lore.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 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.