| 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: <20110424.222824.193712645.davem@davemloft.net> Date: Sun, 24 Apr 2011 22:28:24 -0700 (PDT) From: David Miller <davem@...emloft.net> To: bhutchings@...arflare.com Cc: maheshb@...gle.com, netdev@...r.kernel.org, mirq-linux@...e.qmqm.pl Subject: Re: [PATCH 2/9] net-ethtool: Convert (hw_/vlan_/wanted_)features fields from u32 type to u64. From: Ben Hutchings <bhutchings@...arflare.com> Date: Sun, 24 Apr 2011 06:30:40 +0100 > If we think 64 bits will be enough for the next 10 years, then let's > just go with a single 64-bit feature word. If we're not so sure then > then the ethtool API should continue to allow for multiple words > (whether 32-bit or 64-bit). I think the ethtool facing stuff should stay as is. Having total flexibility internally is important. I know some people had reservations about using the bitmap interfaces, but that's what they exist for. The approach for the conversion just wasn't right. My humble suggestion is: 1) Abstract away every access to these feature sets, like this. void netdev_set_feature(struct net_device *netdev, int feature); void netdev_clear_feature(struct net_device *netdev, int feature); bool netdev_test_feature(struct net_device *netdev, int feature); Then you can use whatever representation you want, without having to edit hundreds of files every time we want to change how these feature sets are stored. Thus, after this, future changes will be painless. This is a multi-commit change. First you add the interfaces, then you change the access sites in logical groups. 2) Write translators between the internal representation and the ethtool user-visible data structures we have for this stuff. 3) Pick an extensible set implementation and use it. We may need to have a type that gets used to pass feature sets around, and if that's absolutely needed, then fine. But it has to be a typedef or similar, so that it can be changed without having to change every function signature every time we want to change the representation. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists