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

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] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 12 Jun 2016 13:34:12 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	David Miller <davem@...emloft.net>, vidya@...ulusnetworks.com
Cc:	bwh@...nel.org, netdev@...r.kernel.org, roopa@...ulusnetworks.com
Subject: Re: [PATCH net-next] ethtool: Macro definition for SFF-8436/8636
 Memory map max sizes

On Sat, 2016-06-11 at 19:26 -0700, David Miller wrote:
> From: Vidya Sagar Ravipati <vidya@...ulusnetworks.com>
> Date: Sat, 11 Jun 2016 16:22:38 -0700
> 
> > 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.

Ben.

-- 
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)