On 16-07-12 11:12 AM, John W. Linville wrote: > On Tue, Jul 12, 2016 at 01:04:52PM -0500, Jorge Alberto Garcia wrote: >> On Tue, Jul 12, 2016 at 12:55 PM, Jiri Pirko <j...@resnulli.us> wrote: >>> Tue, Jul 05, 2016 at 05:37:42PM CEST, jorge.garcia.gonza...@gmail.com wrote: >>>> Hi ! >>>> >>>> Some days ago, Jiri Pirko was talking about some next steps to >>>> implement for ethtool. >>>> >>>> I haven't seen any follow up since ethtool's maintainer change. Can we have >>>> additional details about these ? >>>> >>>> - libethtool - API >>>> - generic netlink >>> >>> Yep, exactly, no reply. Apparently nobody really want to do any initiative >>> here, and I'm lacking time to do it :( >>> >> >> That's fine, I already got a git repo, I'm trying to understand what >> 'use generic netlink' means. >> >> This is a piece of what grep got me on iproute git repo (I'm still >> trying to understand) >> grep -i netlink -r iproute2/ >> iproute2/bridge/mdb.c:#include "libnetlink.h" >> iproute2/bridge/vlan.c:#include "libnetlink.h" >> ... >> .. > > The general notion would be to replace the current ioctl-based > ethtool API with one that is based on netlink, like many of the other > networking APIs. I'm fine with the general idea of that, but so far > I haven't heard a strong case for why it is necessary. It certainly > doesn't seem urgent to me -- if someone disagrees, then please explain! >
And probably obvious but you can't remove the ioctl based ethtool interface because we have a lot of software using it so you will have to maintain both in parallel if there is a netlink equivalent. Also most the stuff in ethtool tends to be things you set once at init time or for debugging so the benefit of notifiers and such are minimal. Sure if I was doing it from scratch netlink would be better and there are probably parts of it that are worth converting over where notifier hooks and standardizing would be beneficial. I think Roopa for example was coming up with some more general statistics mechanism. My $.02 anyways. JohnF
