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. _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel