[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231011093410.6c330161@kernel.org>
Date: Wed, 11 Oct 2023 09:34:10 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
nicolas.dichtel@...nd.com, fw@...len.de, pablo@...filter.org,
mkubecek@...e.cz, aleksander.lobakin@...el.com
Subject: Re: [RFC] netlink: add variable-length / auto integers
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..
Powered by blists - more mailing lists