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

Message-Id: <20160614.152942.1686747827169238570.davem@davemloft.net>
Date:	Tue, 14 Jun 2016 15:29:42 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	ben@...adent.org.uk
Cc:	vidya@...ulusnetworks.com, 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

From: Ben Hutchings <ben@...adent.org.uk>
Date: Sun, 12 Jun 2016 13:34:12 +0100

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

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.