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]
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

Powered by blists - more mailing lists