[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZSbVqhM2AXNtG5xV@nanopsycho>
Date: Wed, 11 Oct 2023 19:04:42 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, pabeni@...hat.com, davem@...emloft.net,
edumazet@...gle.com, jacob.e.keller@...el.com,
johannes@...solutions.net
Subject: Re: [patch net-next 02/10] tools: ynl-gen: introduce support for
bitfield32 attribute type
Wed, Oct 11, 2023 at 06:52:36PM CEST, kuba@...nel.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?
Powered by blists - more mailing lists