[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170612192238.GF1993@nanopsycho>
Date: Mon, 12 Jun 2017 21:22:38 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: David Ahern <dsahern@...il.com>
Cc: Jamal Hadi Salim <jhs@...atatu.com>, davem@...emloft.net,
netdev@...r.kernel.org, xiyou.wangcong@...il.com,
eric.dumazet@...il.com, simon.horman@...ronome.com,
mrv@...atatu.com
Subject: Re: [PATCH net-next v10 1/4] net netlink: Add new type NLA_FLAG_BITS
Mon, Jun 12, 2017 at 05:00:41PM CEST, dsahern@...il.com wrote:
>On 6/12/17 8:14 AM, Jiri Pirko wrote:
>>>> The thing is, struct nla_flag_bits is tightly coupled with NLA_FLAG_BITS
>>>> enum value. They should be in the same uapi file. That makes sense to me.
>>>>
>>>
>>> Sure - they should be in the same file. But is it uapi/linux/netlink.h?
>>
>> Might be the netlink-types.h you mentioned above.
>>
>> ccing DavidA.
>>
>
>Just saw this patch set this morning. Few comments:
>
>1. I think nla_bitfield or nla_bitmap is a better name than nla_flag_bits
ack
>
>2. The length should be open ended with the size of the array determined
>by nla_len / sizeof(struct nla_bitfield). That allows this to be
>extended to an arbitrary large bitfield as needed.
Yeah, I was thinking about that as well. Seems handy to have this
generic len.
>
>3. IMO since these are nla prefixes and new NLA type they should be in
>uapi/linux/netlink.h
Including NLA_* type enum? I think it is reasonable.
Powered by blists - more mailing lists