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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 04 Aug 2014 15:15:39 -0700 (PDT) From: David Miller <davem@...emloft.net> To: ben@...adent.org.uk Cc: _govind@....com, netdev@...r.kernel.org, ssujith@...co.com, benve@...co.com Subject: Re: [PATCH net-next v2 2/3] ethtool: Add support for DMA buffer settings From: Ben Hutchings <ben@...adent.org.uk> Date: Sat, 02 Aug 2014 14:56:22 +0100 > How about adding a generic operation for independent tunables: > > struct ethtool_get_tunable { > u32 cmd; > u32 id; > u64 value, min, max; > }; > > struct ethtool_set_tunable { > u32 cmd; > u32 id; > u64 value; > }; > > int (*get_tunable)(struct net_device *, struct ethtool_get_tunable *); > int (*set_tunable)(struct net_device *, const struct ethtool_set_tunable *); > > The id to name mapping could be provided either through a stringset or > macros in <uapi/linux/ethtool.h>. And perhaps we could split the id > space to allow for driver-specific tunables (while strongly discouraging > those for in-tree drivers). That would certainly work, and another approach would be that we could also create a tunable namespace of sorts. struct ethtool_tunable { u32 cmd; u32 len; u32 data[]; }; #define ETHTOOL_GTUNABLE x #define ETHTOOL_STUNABLE y ... #define ETHTOOL_TUNABLE_COPYBREAK 0x00000001 /* u32 */ etc. I understand the reason to gravitate towards stringset, in that it would minimize the amount of code needed in the ethtool utility itself. -- 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