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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ