Thread (74 messages) 74 messages, 6 authors, 2019-07-10

Re: [PATCH net-next v6 06/15] ethtool: netlink bitset handling

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2019-07-04 12:03:16
Also in: lkml

On Thu, 2019-07-04 at 13:52 +0200, Michal Kubecek wrote:
There is still the question if it it should be implemented as a nested
attribute which could look like the current compact form without the
"list" flag (if there is no mask, it's a list). Or an unstructured data
block consisting of u32 bit length 
You wouldn't really need the length, since the attribute has a length
already :-)

And then, if you just concatenate the value and mask, the existing
NLA_BITFIELD32 becomes a special case.
and one or two bitmaps of
corresponding length. I would prefer the nested attribute, netlink was
designed to represent structured data, passing structures as binary goes
against the design (just looked at VFINFO in rtnetlink few days ago,
it's awful, IMHO).
Yeah, I dunno. On the one hand I completely agree, on the other hand
NLA_BITFIELD32 already goes the other way, and is there now...
Either way, I would still prefer to have bitmaps represented as an array
of 32-bit blocks in host byte order. This would be easy to handle in
kernel both in places where we have u32 based bitmaps and unsigned long
based ones. Other options seem less appealing:

  - u8 based: only complicates processing
  - u64 based: have to care about alignment
  - unsigned long based: alignment and also problems with 64-bit kernel
    vs. 32-bit userspace
Agree with this.

johannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help