[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <70b51ac5-a7d1-8b52-90c4-7f80ec8ad4d5@mojatatu.com>
Date: Wed, 28 Sep 2016 08:27:24 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: David Miller <davem@...emloft.net>
Cc: gorcunov@...il.com, eric.dumazet@...il.com,
dsa@...ulusnetworks.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, kuznet@....inr.ac.ru,
jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net,
avagin@...nvz.org, stephen@...workplumber.org
Subject: Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets
On 16-09-28 08:16 AM, David Miller wrote:
> From: Jamal Hadi Salim <jhs@...atatu.com>
> Date: Wed, 28 Sep 2016 08:09:28 -0400
>
>> On 16-09-28 08:07 AM, David Miller wrote:
>>
>>> Right, it would be legal for an existing user to have code that
>>> explicitly initializes every member of the structure, including 'pad'.
>>> So we have to keep that member around, at a minimum, for their sake.
>>>
>>
>> I think we need to start labelling any new pad fields added as
>> "Not UAPI. Do not fsck fondle this".
>
> They must initialize it to zero.
>
What if in the future actually meant to use 0 for
something?;-> For example in Cyrill's case it means PROTO_IP
Not sure if it useful to interpret or not but it is part of the
enum for protocols.
Maybe we shouldnt be adding pad fields in these netlink
structure definitions then one can liberally add new ones.
Note: inet_diag somewhere has a netlink structure that
has a hole. I pointed it out to Eric D. and he said we cant
add it now because it would break ABI.
So where do we draw the line for future extensions?
cheers,
jamal
Powered by blists - more mailing lists