Re: [PATCH net-next] ethtool: Macro definition for SFF-8436/8636 Memory map max sizes

From: Ben Hutchings <redacted>
Date: Sun, 12 Jun 2016 13:34:12 +0100

On Sat, 2016-06-11 at 19:26 -0700, David Miller wrote:

quoted

From: Vidya Sagar Ravipati <redacted>
Date: Sat, 11 Jun 2016 16:22:38 -0700

quoted

As part of ethtool application, application is requesting  the drivers
to provide the supported eeprom size to allocate memory buffer for
getting complete dump.

And the right way to do that is the driver requests the eeprom info
with a buffer size of zero, then the driver fills in the size field
for what the size actually is.

Then the application can allocate the proper buffer size and rerun
the eeprom request.

Putting endless values for each and every eeprom type a device has is
just rediculous.

I'm not going to continue promoting this broken and unscalable scheme,
we have to fix this.

I don't think there's nothing broken here.  ethtool doesn't use those
macros, the drivers do.

If it's a value only for the drivers, then why does it need to be in a
public UAPI header file and exported outside of the kernel at all?

If it's a private driver detail, it should live in the driver.