[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140804.151539.185781551061535031.davem@davemloft.net>
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