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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 19 Nov 2019 13:28:34 +0000
From:   Shay Drory <shayd@...lanox.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Maor Gottlieb <maorg@...lanox.com>,
        Eran Ben Elisha <eranbe@...lanox.com>,
        "lennart@...ttering.net" <lennart@...ttering.net>,
        Saeed Mahameed <saeedm@...lanox.com>,
        lorian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "systemd-devel@...ts.freedesktop.org" 
        <systemd-devel@...ts.freedesktop.org>,
        Jiri Pirko <jiri@...lanox.com>,
        "mkubecek@...e.cz" <mkubecek@...e.cz>
Subject: Re: Send SFP event from kernel driver to user space (UDEV)

On 11/19/2019 01:19, Andrew Lunn wrote:
> On Mon, Nov 18, 2019 at 11:54:31AM +0000, 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.
> Hi Shay
>
> So you are proposing something which won't work for the generic SFP
> code?  That should be an automatic NACK. Whatever you propose needs to
> be generic so that it can work for any NICs that do firmware support
> for SFPs, and those who let Linux handle the SFP.

The suggestion is targeted to support all types of NICs
that do firmware support for SFPs. But I want to do it via the ethtool-nl
interface and not by using phy drivers.

>
>> 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.
> What exactly are you interested in? What are your use cases. When
> hwmon devices are created, you should get udev events. Maybe that is
> sufficient? Or are you interested in some other parts of the SFP than
> the diagnostic sensors?

It looks like the hwmon is not sufficient for out purpose. I am interesting
in getting events when the SFP is inserted or removed.

>
>>> 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?
> I don't particularly like two ways to get the same information. It
> means we have two APIs we need to maintain forever, when just one
> should be sufficient.
>
>>> 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.
> So you do plan to have a udev daemon running in every network name
> space. Does udev even support that?
>
> I'm sceptical using udev is a good idea. But having netlink events
> does sounds reasonable. And if you are willing to wait a while,
> ethtool-nl does seem like a good fit. But please make sure your
> solution is generic.
>
> 	 Andrew

Thanks for your comments. The using of Udev is under internal discussion.