Re: [RFC] netlink: add variable-length / auto integers

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 11 Oct 2023 18:21:47 +0200 Johannes Berg wrote:
> > > It's a bit confusing, perheps better just to use nla_put() here as well?  
> > 
> > I want to underscore the equivalency to u32 for smaller types.  
> 
> ITYM "smaller values".

Right, sorry.

> Now I'm wondering if we should keep ourselves some option of going to
> even bigger values (128 bits) in some potential future, but I guess
> that's not really natively supported anywhere in the same way 64-bit is
> supposed on 32-bit.

I was wondering the same. And in fact that's what kept me from posting
this patch for like a year. Initially I was envisioning a Python-style
bigint, then at least a 128b int, then I gave up.

The problem is I have no idea how to handle large types in C.
Would nla_get_uint() then return uint128_t?  YNL also needs to turn the
value into the max width type and put it in a "parsed response struct".
Presumably that'd also have to render all uints as uint128_t..

If we can't make the consumers reliably handle 128b there's no point 
in pretending that more than 64b can be carried. 
I'm not even sure if all 32b arches support u128.

Given that we have 0 uses of 128b integers in netlink today, I figured
we're better off crossing that bridge when we get there..