netdev - Re: [PATCH] optoe: driver to read/write SFP/QSFP EEPROMs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20180622072834.GA18945@lunn.ch>
Date:   Fri, 22 Jun 2018 09:28:34 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Don Bollinger <don@...bollingers.org>
Cc:     netdev <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH] optoe: driver to read/write SFP/QSFP EEPROMs

> Got it.  I'm targeting a different market, with a different
> architecture.  In this architecture it makes more sense to separate the
> EEPROM access from the IO pins control.

The fact you are targeting a different architecture is why you are
getting no traction. The closer you stick to the kernel architecture,
the more acceptable your changes are going to be.

> > have a network interface per port. So they cannot use ethtool
> > --module-info, which IS the defined API to get access to SFP
> > data. Adding another API is probably not going to get accepted.
> 
> Got it.  I don't think I'm adding another API.  Note that Cumulus is
> using the same architecture as optoe, and providing all the expected
> linux services, including ethtool --module-info.

Please point me to the in kernel code.

Cumulus has a lot of code out of mainline, which does not follow the
mainline way of doing things. Cumulus is between a rock and a hard
place. There are some switch vendors who simply won't do things the
netdev way. So they have to make use of the vendor SDKs. But they also
work with vendors like Mellonex which fully do things netdev way. So
you cannot use Cumulus as a reference, without pointing to actual in
kernel code.

> I'm offering an improvement to sfp.c.  The improvement is access to more
> pages of SFP EEPROM, and access to QSFP EEPROMs.  It comes in the form of
> a specialized EEPROM driver custom built for {Q}SFP devices.  I'm also
> offering to help integrate that driver into sfp.c.  I can modify optoe
> to accomodate sfp.c, I can recommend how to instantiate and call it. I am
> not going to be able to spend the time and money required to modify and
> test sfp.c.  I'm pretty sure you can do it MUCH faster, and MUCH better
> than I can.

You are however going the wrong way. We want ethtool --module-info to
show QSFP contents, and that is the only API the kernel needs to the
raw data. The core of optoe for accessing the EEPROM could be merged
into the SFP code, but the way optoe it exposes it via /sysfs is
unlikely to be accepted.

> > the SFP code. It has been on my TODO list to add HWMON support for the
> > temperature sensors, etc.
> 
> Huh.  Just read Documentation/hwmon/sysfs-interface.  Looks like a good
> way to deliver that EEPROM data.  Wish I'd found that two years ago when
> there were a few more dimes available.

Well, it is not all the EEPROM data. Just sensors. But that is the
kernel way of exporting sensors.

       Andrew