From: David Miller <davem@davemloft.net>
To: bhutchings@solarflare.com
Cc: maheshb@google.com, netdev@vger.kernel.org, mirq-linux@rere.qmqm.pl
Subject: Re: [PATCH 2/9] net-ethtool: Convert (hw_/vlan_/wanted_)features fields from u32 type to u64.
Date: Sun, 24 Apr 2011 22:28:24 -0700 (PDT) [thread overview]
Message-ID: <20110424.222824.193712645.davem@davemloft.net> (raw)
In-Reply-To: <1303623041.3032.97.camel@localhost>
From: Ben Hutchings <bhutchings@solarflare.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.
next prev parent reply other threads:[~2011-04-25 5:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-22 23:35 [PATCH 0/9] Convert features fields from u32 to type u64 Mahesh Bandewar
2011-04-22 23:35 ` [PATCH 1/9] net-dev: Convert (hw_/vlan_/wanted_)features fields from u32 type to u64 Mahesh Bandewar
2011-04-22 23:36 ` [PATCH 2/9] net-ethtool: " Mahesh Bandewar
2011-04-22 23:36 ` [PATCH 3/9] net-core: " Mahesh Bandewar
2011-04-22 23:36 ` [PATCH 4/9] net-tcp: " Mahesh Bandewar
2011-04-22 23:36 ` [PATCH 5/9] net-udp: " Mahesh Bandewar
2011-04-22 23:36 ` [PATCH 6/9] net-vlan: " Mahesh Bandewar
2011-04-22 23:36 ` [PATCH 7/9] net-bridge: " Mahesh Bandewar
2011-04-22 23:36 ` [PATCH 8/9] net-ipv4: " Mahesh Bandewar
2011-04-22 23:36 ` [PATCH 9/9] net-ipv6: " Mahesh Bandewar
2011-04-24 5:30 ` [PATCH 2/9] net-ethtool: " Ben Hutchings
2011-04-25 5:28 ` David Miller [this message]
2011-04-25 18:14 ` Mahesh Bandewar
2011-04-25 8:48 ` Michał Mirosław
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110424.222824.193712645.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=bhutchings@solarflare.com \
--cc=maheshb@google.com \
--cc=mirq-linux@rere.qmqm.pl \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).