RE: Re-send (What else needs to be done to the sep driver(staging/sep))

From: Allyn, Mark A
Date: Thu Apr 14 2011 - 10:47:24 EST

-----Original Message-----
From: Joe Perches [mailto:joe@xxxxxxxxxxx]
Sent: Wednesday, April 13, 2011 4:13 PM
To: Greg KH
Cc: Allyn, Mark A; linux-kernel@xxxxxxxxxxxxxxx; alan@xxxxxxxxxxxxxxx; 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at