| 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
| ||
|
Date: Mon, 18 Apr 2016 05:50:05 +0000 From: Yuval Mintz <Yuval.Mintz@...gic.com> To: David Miller <davem@...emloft.net> CC: netdev <netdev@...r.kernel.org>, Sudarsana Kalluru <Sudarsana.Kalluru@...gic.com> Subject: Re: [PATCH net-next 5/5] qed*: Add support for read/write of eeprom >> The third option I see is to completely ditch this, stating that although >> We obviously CAN set the non-volatile memory we CAN'T do it with the >> regular API, and to move into doing this via some proprietary API such >> as debugfs. > Why go to debugfs rather than gracefully extending the ethtool stuff to > explicitly support what you need? Gracefully extend it to where? The most I can learn from this is that some adapters are in need of additional metadata for doing this sort of stuff. The state-machine itself is propriety and I don't think anyone would gain from trying to formalize anything else from it. If by 'graceful extension' of ethtool API you mean adding an additional field or two for metadata - sure, I can do that, I just don't think of it as graceful. ;-) And if this is actually the way we want to take this, I would still [don't get upset ;-)] argue in favor of overloading the 'magic' field for this purpose, as bnx2x and bnxt are already doing. Basically if the 'magic' would also contain metadata that could be verified as appropriate [I.e., by having valid ranges], it would still fit as a safety measure for guaranteeing the correctness of the write request.
Powered by blists - more mailing lists