Hello Srinivas,
I am currently looking at the Open Compute Project ONIE Tlv tables in
modern networking hardware. Thanks to the specification being available
for many years and rather easy to implement, those tables are already
present in many switches. Manufacturers just have to provide a small
storage medium exposing factory-related information (manufacturer, date,
serial#, mac addresses, etc) in Type-Length-Value fields, as well
as their own extensions if they want. These tables are common, but
there is currently no shared decoding logic, each provider maintaining
its own internally.
I am currently looking for upstreaming an nvmem layout driver for
exposing the standard nvmem cells. This way, Ethernet drivers might eg.
take the base MAC address from there. But I feel like there is
something missing, because the vendor name, the device version, the
serial number or any other information available in these tables might
also very well be used by the userspace rather than the kernel drivers
only.
Thus, I was wondering if there was some ongoing work to make these
cells available to userspace (in /sys maybe?) or if this had already
been discussed somewhere. Otherwise, would you be open to such a
contribution? I guess it would also be a useful debug tool anyway (and
might very well be moved somewhere else than in /sys).
Thanks for your time,
Miquèl
On 22/09/2022 11:23, Miquel Raynal wrote:
> Hello Srinivas,
>
> I am currently looking at the Open Compute Project ONIE Tlv tables in
> modern networking hardware. Thanks to the specification being available
> for many years and rather easy to implement, those tables are already
> present in many switches. Manufacturers just have to provide a small
> storage medium exposing factory-related information (manufacturer, date,
> serial#, mac addresses, etc) in Type-Length-Value fields, as well
> as their own extensions if they want. These tables are common, but
> there is currently no shared decoding logic, each provider maintaining
> its own internally.
>
> I am currently looking for upstreaming an nvmem layout driver for
> exposing the standard nvmem cells. This way, Ethernet drivers might eg.
> take the base MAC address from there. But I feel like there is
> something missing, because the vendor name, the device version, the
> serial number or any other information available in these tables might
> also very well be used by the userspace rather than the kernel drivers
> only.
Could you explain the userspace side use-case?
>
> Thus, I was wondering if there was some ongoing work to make these
> cells available to userspace (in /sys maybe?) or if this had already
> been discussed somewhere. Otherwise, would you be open to such a
we had this discussed this in many instances and this is some thing we
would desire to have but we never got it moving forward.
> contribution? I guess it would also be a useful debug tool anyway (and
> might very well be moved somewhere else than in /sys).
getting sysfs working correctly in sync with userspace might be tricky
in this particular case as we will be creating cells after the provider
driver is created.
debugfs on the other hand is more doable.
--srini
>
> Thanks for your time,
> Miquèl
Hi Srinivas,
[email protected] wrote on Thu, 22 Sep 2022 22:33:52 +0100:
> On 22/09/2022 11:23, Miquel Raynal wrote:
> > Hello Srinivas,
> >
> > I am currently looking at the Open Compute Project ONIE Tlv tables in
> > modern networking hardware. Thanks to the specification being available
> > for many years and rather easy to implement, those tables are already
> > present in many switches. Manufacturers just have to provide a small
> > storage medium exposing factory-related information (manufacturer, date,
> > serial#, mac addresses, etc) in Type-Length-Value fields, as well
> > as their own extensions if they want. These tables are common, but
> > there is currently no shared decoding logic, each provider maintaining
> > its own internally.
> >
> > I am currently looking for upstreaming an nvmem layout driver for
> > exposing the standard nvmem cells. This way, Ethernet drivers might eg.
> > take the base MAC address from there. But I feel like there is
> > something missing, because the vendor name, the device version, the
> > serial number or any other information available in these tables might
> > also very well be used by the userspace rather than the kernel drivers
> > only.
>
> Could you explain the userspace side use-case?
Right now I don't have any TBH. But in general, having access to a
serial number, a manufacturing date, a hardware batch or whatever other
per-device factory information is always useful.
> > Thus, I was wondering if there was some ongoing work to make these
> > cells available to userspace (in /sys maybe?) or if this had already
> > been discussed somewhere. Otherwise, would you be open to such a
>
> we had this discussed this in many instances and this is some thing we would desire to have but we never got it moving forward.
Ok.
> > contribution? I guess it would also be a useful debug tool anyway (and
> > might very well be moved somewhere else than in /sys).
>
> getting sysfs working correctly in sync with userspace might be tricky in this particular case as we will be creating cells after the provider driver is created.
>
> debugfs on the other hand is more doable.
Ok, I might try something with debugfs then. I'll keep this in mind.
Thanks,
Miquèl