[lkml]   [2011]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: Re-send (What else needs to be done to the sep driver (staging/sep))

-----Original Message-----
From: Joe Perches []
Sent: Wednesday, April 13, 2011 4:13 PM
To: Greg KH
Cc: Allyn, Mark A;;; Mangalampalli, Jayant; Gokulrangan, Venkat R
Subject: Re: Re-send (What else needs to be done to the sep driver (staging/sep))

On Wed, 2011-04-13 at 15:46 -0700, Greg KH wrote:
> I don't like seeing every individual driver have its own way of handling
> debug macros, that's crazy.

That's your preference not mine.

> For larger stuff like networking, yes, they can do that, and that's
> fine. They also were doing this before the dev_* macros came along,
> just like USB did, so there is historical precident there.

I added netdev_<level> and netif_<level>.

> But again, not for a new driver, don't redefine the existing macros just
> because you don't like typing a few extra characters...

You are not the driver maintainer and those decisions
are driver maintainer decisions not yours.

Check this out:

$ grep -rP -oh --include=*.[ch] \
"\b[a-z]+_(dbg|alert|crit|emerg|notice|warn|err|info)\b\s*\(" drivers | \
sed -e 's/(//g' -r -e 's/\s*//g' | \
sort | uniq | wc -l

Most all of those are different logging forms.

So, not crazy, just not your preference.

I've put in some effort trying to standardize logging
messages and mechanisms as well, and I think

<prefix>_<level>(struct *, fmt, ..._

is a perfectly good and understandable style.

I do not suggest using some arbitrary prefix just for the
sake of it, only when there is a specific structure that
can be used.

cheers, Joe


I am adding Alan Cox, Mark Gross, and Bruce Beare into the discussion.

I will not do anything to change the logging in this driver until I get
better clarification from Mark, Alan, and Bruce as well as Greg.


Mark Allyn

 \ /
  Last update: 2011-04-14 16:49    [W:0.054 / U:0.028 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site