Re: [PATCH net-next v2 0/2] Add support for DSFP transceiver type

[Andrew Lunn <andrew@lunn.ch>]

> OK, but if the caching system is checking one time netlink and one time
> ioctl, it means this cache should be in user space, or did you mean to have
> this cache in kernel ?

This is all in userspace, in the ethtool code.

> > > What about the global offset that we currently got when user doesn't specify
> > > a page, do you mean that this global offset goes through the optional and
> > > non optional pages that exist and skip the ones that are missing according
> > > to the specific EEPROM ?
> > ethtool -m|--dump-module-eeprom|--module-info devname [raw on|off] [hex on|off] [offset N] [length N]
> > 
> > So you mean [offset N] [length N].
> 
> 
> Yes, that's the current options and we can either try coding new
> implementation for that or just call the current ioctl implementation. The
> new code can be triggered once options [bank N] and [Page N] are used.

You cannot rely on the ioctl being available. New drivers won't
implement it, if they have the netlink code. Drivers will convert from
get_module_info to whatever new ndo call you add for netlink.

> OK, if I got it right on current API [offset N] [length N] just call ioctl
> current implementation, while using the option [raw on] will call new
> implementation for new SFPs (CMIS 4). Also using [bank N] and [page N] will
> call new implementation for new SFPs.

Not just CMIS. All SFPs.

    Andrew