linux-kernel - Re: [PATCH net-next 1/6] tools: ynl-gen: bitshift the flag values in the generated code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251014122441.27e2d267@kernel.org>
Date: Tue, 14 Oct 2025 12:24:41 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Asbjørn Sloth Tønnesen
 <ast@...erby.net>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Alexei Starovoitov
 <ast@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>, Arkadiusz Kubalewski
 <arkadiusz.kubalewski@...el.com>, Daniel Borkmann <daniel@...earbox.net>,
 Daniel Zahka <daniel.zahka@...il.com>, Donald Hunter
 <donald.hunter@...il.com>, Jacob Keller <jacob.e.keller@...el.com>, Jesper
 Dangaard Brouer <hawk@...nel.org>, Jiri Pirko <jiri@...nulli.us>, Joe
 Damato <jdamato@...tly.com>, John Fastabend <john.fastabend@...il.com>,
 Jonathan Corbet <corbet@....net>, Simon Horman <horms@...nel.org>,
 Stanislav Fomichev <sdf@...ichev.me>, Toke Høiland-Jørgensen <toke@...hat.com>, Vadim Fedorenko
 <vadim.fedorenko@...ux.dev>, Willem de Bruijn <willemb@...gle.com>,
 bpf@...r.kernel.org, netdev@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 1/6] tools: ynl-gen: bitshift the flag values
 in the generated code

On Tue, 14 Oct 2025 16:49:22 +0000 Asbjørn Sloth Tønnesen wrote:
> On 10/14/25 12:53 AM, Jakub Kicinski wrote:
> > On Mon, 13 Oct 2025 16:49:58 +0000 Asbjørn Sloth Tønnesen wrote:  
> >> Instead of pre-computing the flag values within the code generator,
> >> then move the bitshift operation into the generated code.
> >>
> >> This IMHO makes the generated code read more like handwritten code.  
> > 
> > I like it the way it is. The values are irrelevant.  
> 
> Bit-shifting seams like the preferred way across the uAPI headers.
> 
> Would you be open to hexadecimal notation, if not bit-shifting?
> 
> Currently NLA_POLICY_MASK() is generated with a hexadecimal mask, and
> with these patches, if render-max is not set. If using literal values
> then we should properly consistently generate them as either decimal
> or hexadecimal. I prefer hexadecimal over decimal.

Hm, hex could do. For the bit/1 << x i really don't like that the values
are not aligned to columns, so they visually mix in with the names. 
But aligning them would be more LoC than it's worth.

hex could be a reasonable compromise, but I make no promise that I will
like it once I see the result :)

> > And returning a string from user_value() is quite ugly.  
> It only returns a string, when as_c is set, I am happy to duplicate
> some code instead, and add a dedicated method always returning a string,
> but can we please agree on the generated output, before implementation?

nlspec.py was supposed to be a library that abstracts away things like
default values not being present, and simplifies indexing. So having a
"give me a format for C as result" arg is not great for layering.
That kind of logic belongs in the caller. 

Regarding LoC - great code is concise, but that doesn't mean that
making code shorter always makes it better.