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
| ||
|
Message-Id: <20160611.192648.91885921700006865.davem@davemloft.net> Date: Sat, 11 Jun 2016 19:26:48 -0700 (PDT) From: David Miller <davem@...emloft.net> To: 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 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.
Powered by blists - more mailing lists