[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140717163812.GA20406@mikrodark.usersys.redhat.com>
Date: Thu, 17 Jul 2014 18:38:13 +0200
From: Veaceslav Falico <vfalico@...il.com>
To: Joe Perches <joe@...ches.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Tom Gundersen <teg@...m.no>
Subject: Re: [PATCH v2 net-next 1/2] net: use dev->name in netdev_pr* when
it's available
On Thu, Jul 17, 2014 at 09:36:08AM -0700, Joe Perches wrote:
>On Thu, 2014-07-17 at 18:25 +0200, Veaceslav Falico wrote:
>> On Thu, Jul 17, 2014 at 09:18:44AM -0700, Joe Perches wrote:
>> >On Thu, 2014-07-17 at 16:09 +0200, Veaceslav Falico wrote:
>> >> netdev_name() returns dev->name only when the net_device is in
>> >> NETREG_REGISTERED state.
>[]
>> >Maybe this should not be inline and become something like:
>>
>> It will miss the states then, when it's not NETREG_REGISTERED.
>
>If it's registered, it has a valid name via
>dev_get_valid_name() doesn't it?
Yes, I'm speaking about the NETREG_* states when it's not registered.
i.e.:
Jul 17 13:35:29 darkmag kernel: [ 602.686489] bond2 (unregistering): Released all slaves
that's with my patchset, when the bond device is unregistering
(NETREG_UNREGISTERING). With your patch it would be only "bond2: Released
all slaves".
As the most time the device is in the NETREG_REGISTERED state, there will
be no differencies in the output (with either my or your approach), however
in less-common states/codepaths it will also output its state, which might
be quite valuable when analyzing the logs.
>
>> >const char *netdev_name(const struct net_device *dev)
>> >{
>> > if (dev->reg_state == NETREG_REGISTERED)
>> > return dev->name;
>> >
>> > if (!dev->name[0])
>> > return "(unnamed net_device)";
>> >
>> > if (!strchr(dev->name, '%'))
>> > return "(unregistered net_device)";
>> >
>> > return dev->name;
>> >}
>> >EXPORT_SYMBOL(netdev_name);
>
>
>
--
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