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

[Allyn, Mark A]

-----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
266

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.

Thanks

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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/