Re: [PATCH v2 0/4] ethdev: report module signal status flags

[Roman Khromenok <roma55592@yandex.ru>]

On Fri, 9 Oct 2026, Thomas Monjalon wrote:
> This is specific to networking devices, right?
> So it has to be linked with ethdev probably.
> But if it is not specific to any driver,
> we may consider moving it to separate library.
> I'm not sure which place is best.

Yes, these are the pluggable transceivers of network ports, but
nothing in the decoding is driver specific. Drivers only return
the raw EEPROM bytes through the get_module_eeprom op, and the
decoding follows the SFF specifications. The decoder (about 2700
lines) uses ethdev only for the RTE_ETH_MODULE_SFF_* type values
and the callback typedef.

So ethdev would keep linking it, the same way it depends on net
and meter: ethdev depends on the new library, not the other way.
rte_eth_dev_get_module_eeprom() and the telemetry command stay
in ethdev and call the library.

The decoder is also useful for ports which are not ethdev ports:
in our firewall, the kernel ports are read with the ethtool ioctls
and decoded with a copy of the same code. This already works with
rte_eth_module_eeprom_parse(), so a separate library is mostly
about keeping ethdev smaller, especially when CMIS is added,
which is about the size of the SFF-8636 decoder.

Keeping it in ethdev is fine with me too. If you prefer that,
I will add CMIS there.