[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1266462064.5719.78.camel@obelisk.thedillows.org>
Date: Wed, 17 Feb 2010 22:01:04 -0500
From: David Dillow <dave@...dillows.org>
To: David Miller <davem@...emloft.net>
Cc: joe@...ches.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 14/15] drivers/net/typhoon.c: Use
(pr|netdev)_<level> macro helpers
On Wed, 2010-02-17 at 18:41 -0800, David Miller wrote:
> From: David Dillow <dave@...dillows.org>
> Date: Wed, 17 Feb 2010 21:30:21 -0500
>
> > No, because the routines that use tp->name are called both before and
> > after the netdev is registered. Prior to that time, it contains the PCI
> > slot name -- "00:01.0" etc -- so that the user can determine which card
> > is acting up. Once the card is registered, it has "ethX" to use a
> > commonly expected name for the card.
>
> In my opinion that's awful.
Neither you nor Jeff seemed to think it was an issue 7+ years ago, and
Jeff liked it when it was suggested as a solution to another driver's
problems. But times change, sure. And people learn from experience.
I liked it because it consistent with eth device naming when it could
be, and gave them useful info to go on when it failed during
initialization. This well before dev_*(). I don't think it is
particularly broken today -- even if we added the PCI info, I'd still
want to know if it was eth0 or eth8 that died on me without having to go
track down which one belonged to the slot.
In any event, that's not going to be cleaned up tonight.
I'm perfectly fine with the netdev_<level> changes, and can grudgingly
live with the overlong format strings, but the pr_<level> changes make
the output worse, and don't help readability or maintainability in my
opinion. I'm don't see how dropping the typhoon patch slows Joe down, so
I'd like to avoid having to fix things up after the fact.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists