Re: [RFC PATCH net-next 0/4] ethtool: Add ability to write to transceiver module EEPROMs

[Andrew Lunn <andrew@lunn.ch>]

> I fail to understand this logic. I would understand pushing
> functionality into the kernel in order to create an abstraction for user
> space over different hardware interfaces from different vendors. This is
> not the case here. Nothing is vendor specific. Not to the host vendor
> nor to the module vendor.

Hi Ido

My worry is, we are opening up an ideal vector for user space drivers
for SFPs. And worse still, closed source user space drivers. We have
had great success with switchdev, over a hundred supported switches,
partially because we have always pushed back against kAPIs which allow
user space driver, closed binary blobs etc.

We have the choice here. We can add a write method to the kAPI, add
open source code to Ethtool using that API, and just accept people are
going to abuse the API for all sorts of horrible things in user space.
Or we can add more restrictive kAPIs, put more code in the kernel, and
probably limit user space doing horrible things. Maybe as a side
effect, SFP vendors contribute some open source code, rather than
binary blobs?

I tend to disagree about adding kAPIs which allow write. But i would
like to hear other peoples opinions on this.

     Andrew