Re: Send SFP event from kernel driver to user space (UDEV)

[Shay Drory <shayd@xxxxxxxxxxxx>]

On 11/18/2019 13:54, Shay Drory wrote:
> On 11/18/2019 03:29, Andrew Lunn wrote:
>> On Sun, Nov 17, 2019 at 11:46:15AM +0000, Shay Drory wrote:
>>
>> Hi Shay
>>
>> It would be good to Cc: the generic SFP code maintainers.
> The suggested solution is not targeted for SFP drivers (see below),
> but I added them to the Cc list.
>
>>> Today, SFP inserted / removal event impacts only the kernel space drivers.
>>> There are users who wishes to get SFP insert / removal in a udev-event
>>> format for their application / daemons / monitors.
>>> The naive way to implement this feature would be to create a sysfs file
>>> that represents device SFP, to expose it under the netdev sysfs, and
>>> to raise a udev event over it.
>>> However, it is not reasonable to create a sysfs for each net-device.
>>> In this letter, I would like to offer a new mechanism that will add a
>>> support to send SFP events from the kernel driver to user space.
>>> This suggestion is built upon a new netlink infrastructure for ethtool
>>> currently being written by Michal Kubeckwhich called “ethtool-netlink”[1].
>> So you are in no rush to make use of this? ethtool-nl seems to be
>> making very slow progress.
> I am looking for the correct solution that we can push to kernel open source.
> The ethtool-nl seems like a good path. If you have another suggestion,
> base on existing code, I will be glad to hear.
>
>>> My suggestion is to do it by adding a function
>>> (ethtool_sfp_insterted/removed(...)) to ethtool API, This function will
>>> raise a netlink event to be caught in user space.
>> What about the case of the SFP is inserted before the SFP is
>> associated to a netdev? Similarly, the SFP is ejected when the SFP is
>> not connected to a MAC. You don't have a netdev, so you cannot send an
>> event. And SFF, which are never inserted or removed? SFPs have a
>> different life cycle to a netdev. Do you care about this?
> The feature is targeted to netdev users. It is expected from the user to query current state via
> ethtool -m and afterwards monitor for changes over UDEV.
>
>>> The design:
>>>
>>> - SFP event from NIC caught by the driver
>>> - Driver call ethtool_sfp_inserted/removed()
>>> - Ethtool generated netlink event with relevant data
>>> - This event-message will be handled in the user-space library of UDEV
>>> (for this purpose we would like to add a netlink infrastructure to UDEV
>>> user-space library).
>> Would you add just SFP insert/eject to UDEV. Or all the events which
>> get sent via netlink? Link up/down, route add/remove, etc?
> It makes sense to notify all events. What do you think?
>
>> What sort of daemon is this anyway? Most networking daemons already
>> have the code to listen to netlink events. So why complicate things by
>> using UDEV?
> That is a good point, we will discuss it internally.
>
>> Is UDEV name space aware? Do you run a udev daemon in each network
>> name space? I assume when you open a netlink socket, it is for just
>> the current network namespace?
> UDEV will follow netlink name-space.
>
>>       Andrew
> Thanks for your comments, Shay.
>
>

_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel