[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b3cd61506080143f571d6286223ae33c8bd02c3a.camel@sipsolutions.net>
Date: Wed, 03 Jul 2019 15:44:57 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Jiri Pirko <jiri@...nulli.us>, Michal Kubecek <mkubecek@...e.cz>
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
John Linville <linville@...driver.com>,
Stephen Hemminger <stephen@...workplumber.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v6 06/15] ethtool: netlink bitset handling
On Wed, 2019-07-03 at 13:49 +0200, Jiri Pirko wrote:
>
> > +Value and mask must have length at least ETHTOOL_A_BITSET_SIZE bits rounded up
> > +to a multiple of 32 bits. They consist of 32-bit words in host byte order,
>
> Looks like the blocks are similar to NLA_BITFIELD32. Why don't you user
> nested array of NLA_BITFIELD32 instead?
That would seem kind of awkward to use, IMHO.
Perhaps better to make some kind of generic "arbitrary size bitfield"
attribute type?
Not really sure we want the complexity with _LIST and _SIZE, since you
should always be able to express it as _VALUE and _MASK, right?
Trying to think how we should express this best - bitfield32 is just a
mask/value struct, for arbitrary size I guess we *could* just make it
kind of a binary with arbitrary length that must be a multiple of 2
bytes (or 2 u32-bit-words?) and then the first half is the value and the
second half is the mask? Some more validation would be nicer, but having
a generic attribute that actually is nested is awkward too.
johannes
Powered by blists - more mailing lists