> I see where you're coming from, but if people start needing to manually
> configure FEC on their consumer devices, possibly we have bigger
> problems.
Yes, i agree with that. For the consumer market, SFPs needs to grow up
and start doing full and reliable auto-neg, just like copper Ethernet.
However, there is often an intermediate step after the really niche
market like TOR routers. Industrial applications start using this
stuff. There are a lot of planes flying today using SFPs for the
inflight entertainment systems. Fibre weights less than copper. It is
a somewhat specialist market, so you probably can still force them to
read the hardware manual, but i think they would prefer not to. And
i'm sure they are not the only industrial users. There are likely to
be more industrial users than TOR users.
In general, it is hard to know which APIs are going to remain Unix
Wizard level, and which are going to be used by mere mortals. So
ideally, we want consistency everywhere.
> I think the alternative, of finding a set of semantics that fits
> everyone's hardware and covers everyone's requirements, is likely to
> be difficult (and probably require changing the ethtool API).
Now is a good time to change the API, since we are moving to a netlink
socket. Which is why these questions were asked in the first place...
Andrew
