Re: [patch net-next 02/10] tools: ynl-gen: introduce support for bitfield32 attribute type

[Jiri Pirko <jiri@resnulli.us>]

Wed, Oct 11, 2023 at 06:52:36PM CEST, kuba@kernel.org wrote:
>On Wed, 11 Oct 2023 08:07:12 +0200 Jiri Pirko wrote:
>> >> Note that since the generated code works with struct nla_bitfiel32,
>> >> the generator adds netlink.h to the list of includes for userspace
>> >> headers. Regenerate the headers.  
>> >
>> >If all we need it for is bitfield32 it should be added dynamically.
>> >bitfiled32 is an odd concept.  
>> 
>> What do you mean by "added dynamically"?
>
>Scan the family, see if it has any bitfields and only then add 
>the include? It's not that common, no point slowing down compilation
>for all families if the header is not otherwise needed.

Got it. Will try.

>
>> >> diff --git a/Documentation/netlink/genetlink-c.yaml b/Documentation/netlink/genetlink-c.yaml
>> >> index f9366aaddd21..8192b87b3046 100644
>> >> --- a/Documentation/netlink/genetlink-c.yaml
>> >> +++ b/Documentation/netlink/genetlink-c.yaml
>> >> @@ -144,7 +144,7 @@ properties:
>> >>                name:
>> >>                  type: string
>> >>                type: &attr-type
>> >> -                enum: [ unused, pad, flag, binary, u8, u16, u32, u64, s32, s64,
>> >> +                enum: [ unused, pad, flag, binary, bitfield32, u8, u16, u32, u64, s32, s64,
>> >>                          string, nest, array-nest, nest-type-value ]  
>> >
>> >Just for genetlink-legacy, please.  
>> 
>> Why? Should be usable for all, same as other types, no?
>
>array-nest already isn't. I don't see much value in bitfiled32
>and listing it means every future codegen for genetlink will
>have to support it to be compatible. It's easier to add stuff
>than to remove it, so let's not.

Interesting. You want to somehow mark bitfield32 obsolete? But why is
it? I mean, what is the reason to discourage use of bitfield32?