Wed, Aug 29, 2018 at 05:23:58PM CEST, mar...@holtmann.org wrote:
>Hi Jiri,
>
>>> The name value from SET_NETDEV_DEVTYPE only ended up in the uevent sysfs
>>> file as DEVTYPE= information. To avoid any kind of race conditions
>>> between netlink messages and reading from sysfs, it is useful to add the
>>> same string as new IFLA_DEVTYPE attribute included in the RTM_NEWLINK
>>> messages.
>>>
>>> For network managing daemons that have to classify ARPHRD_ETHER network
>>> devices into different types (like Wireless LAN, Bluetooth etc.), this
>>> avoids the extra round trip to sysfs and parsing of the uevent file.
>>>
>>> Signed-off-by: Marcel Holtmann <mar...@holtmann.org>
>>> ---
>>> include/uapi/linux/if_link.h | 2 ++
>>> net/core/rtnetlink.c | 12 ++++++++++++
>>> 2 files changed, 14 insertions(+)
>>>
>>> diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
>>> index 43391e2d1153..781294972bb4 100644
>>> --- a/include/uapi/linux/if_link.h
>>> +++ b/include/uapi/linux/if_link.h
>>> @@ -166,6 +166,8 @@ enum {
>>> IFLA_NEW_IFINDEX,
>>> IFLA_MIN_MTU,
>>> IFLA_MAX_MTU,
>>> + IFLA_DEVTYPE, /* Name value from SET_NETDEV_DEVTYPE */
>>
>> This is not something netdev-related. dev->dev.type is struct device_type.
>> This is a generic "device" thing. Incorrect to expose over
>> netdev-specific API. Please use "device" API for this.
>
>it is not just "device" related since this is a sub-classification of
>ARPHRD_ETHER type as a wrote above. Don't get hang up that this information is
>part of struct device. The dev->dev.type contains strings like "wlan",
>"bluetooth", "wimax", "gadget" etc. so that you can tell what kind of Ethernet
>card you have.
I understand. But using dev->dev.type for that purpose seems like an
abuse. If this is subtype of netdev, it should not be stored in parent
device. I believe that you need to re-introduce this as a part of struct
net_device - preferably an enum - and that you can expose over rtnl (and
net-sysfs).
>
>We can revive the patches for adding this information as IFLA_INFO_KIND, but
>last time they where reverted since NetworkManager did all the wrong decisions
>based on that. That part is fixed now and we can put that back and declare the
>sub-type classification of Ethernet device in two places. Or we just take the
>information that we added a long time ago for exactly this sub-classification
>and provide them to userspace via RTNL.
IFLA_INFO_KIND serves for different purpose. It is for drivers that
register rtnl_link_ops. I don't think it would be wise to mix it with
this.
Btw, could you wrap the sentences at 72 cols? Would be easier to read
that way.
>
>Regards
>
>Marcel
>
