netdev - Re: [PATCH 2/9] net-ethtool: Convert (hw_/vlan_/wanted

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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