David Miller wrote:
quoted text
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Thu, 2 Apr 2009 23:30:42 +0800
> 
>> On Thu, Apr 02, 2009 at 05:14:50PM +0200, Patrick McHardy wrote:
>>> I'd prefer that as well. The only reason to do this is to save a few
>>> bytes and cycles for attribute encapsulation. I don't think this
>>> matters at all, judging by the fact that I've never seen a userspace
>>> implementation using message batching, the current users don't seem
>>> to care about performance *that* much.
>> OK, let's all just keep an eye out for new struct users and see
>> how it goes.
> 
> It might be about time to start working on netlink-2 seriously.
> :-)
> 
> We can start treating it like a real protocol, firmly define
> the endianness of everything to kill all the over-the-wire
> issues, etc. and deal with this 4-byte-align stuff as well.

We could add a setsockopt option for userspace to specify "version 2"
operation. The netlink attributes helpers would need to be aware of
the currently used protocol version and could transparently choose
a different encoding (also taking care of endianess etc). For the
case of one value per attribute this should be a straight-forward
conversion. In case of structures that contain values with different
endianness, we'll probably need to define a new encoding (ideally
also one attribute per value) for version 2.

I'd also suggest to get rid of the 64k attribute and message size
limit at the same time, this is making it quite hard to support
transactional semantics for large updates (f.i. for nf_tables sets).

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html