[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZhjTugJcluEXH3Vz@gauss3.secunet.de>
Date: Fri, 12 Apr 2024 08:24:58 +0200
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Antony Antony <antony.antony@...unet.com>
CC: Florian Westphal <fw@...len.de>, Herbert Xu <herbert@...dor.apana.org.au>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>, "David S. Miller"
<davem@...emloft.net>, David Ahern <dsahern@...nel.org>, Jakub Kicinski
<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Andreas Gruenbacher
<agruenba@...hat.com>, <devel@...ux-ipsec.org>, <netdev@...r.kernel.org>
Subject: Re: [PATCH ipsec-next v2] udpencap: Remove Obsolete
UDP_ENCAP_ESPINUDP_NON_IKE Support
On Thu, Apr 11, 2024 at 07:45:52PM +0200, Antony Antony wrote:
> On Thu, Apr 11, 2024 at 10:22:32 +0200, Steffen Klassert wrote:
> > On Thu, Apr 04, 2024 at 10:51:31AM +0200, Antony Antony wrote:
> > >
> > > diff --git a/include/uapi/linux/udp.h b/include/uapi/linux/udp.h
> > > index 4828794efcf8..1516f53698e0 100644
> > > --- a/include/uapi/linux/udp.h
> > > +++ b/include/uapi/linux/udp.h
> > > @@ -36,7 +36,6 @@ struct udphdr {
> > > #define UDP_GRO 104 /* This socket can receive UDP GRO packets */
> > >
> > > /* UDP encapsulation types */
> > > -#define UDP_ENCAP_ESPINUDP_NON_IKE 1 /* draft-ietf-ipsec-nat-t-ike-00/01 */
> >
> > Please don't remove that, it is part of the ABI.
> > Typically this is left in and marked as: /* unused */
>
> Where exactly should I add /* unused */ ?
>
> I agree, it is part of the ABI. We should be careful when removing. However, the solution to obselete is not clear to me. Would you please elaborte on the solution? I see 3 options. Which one do you prefer? Or is there 4th option?
>
> 1. change the comment and leave the definition
>
> -#define UDP_ENCAP_ESPINUDP_NON_IKE 1 /* draft-ietf-ipsec-nat-t-ike-00/01 */
> +#define UDP_ENCAP_ESPINUDP_NON_IKE 1 /* unused draft-ietf-ipsec-nat-t-ike-00/01 */
I prefer this option. The kernel will return -ENOPROTOOPT if userspace
tries to set that option.
>
> Paul brought up a probable issue with this solution. This means user space would build without error while at runtime user space would fail.
If this still has users, it is not unused :-)
> Also kernel would build if someone add it.
Hopefully that will be catched by the review process.
Powered by blists - more mailing lists