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

[Andrew Lunn <andrew@lunn.ch>]

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 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?

> > 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