[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220207132744.mnk62qaxngswb3dz@westermo.com>
Date: Mon, 7 Feb 2022 14:27:44 +0100
From: Jacques de Laval <Jacques.De.Laval@...termo.com>
To: David Ahern <dsahern@...il.com>
CC: "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
David Ahern <dsahern@...nel.org>, <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/1] net: Add new protocol attribute to IP
addresses
On Fri, Feb 04, 2022 at 09:10:51PM -0700, David Ahern wrote:
> On 2/4/22 11:07 AM, Jacques de Laval wrote:
> >>> @@ -69,4 +70,7 @@ struct ifa_cacheinfo {
> >>> #define IFA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifaddrmsg))
> >>> #endif
> >>>
> >>> +/* ifa_protocol */
> >>> +#define IFAPROT_UNSPEC 0
> >>
> >> *If* the value is just a passthrough (userspace to kernel and back), no
> >> need for this uapi. However, have you considered builtin protocol labels
> >> - e.g. for autoconf, LLA, etc. Kernel generated vs RAs vs userspace
> >> adding it.
> >
> > Agreed. For my own (very isolated) use case I only need the passthrough,
> > but I can see that it would make sense to standardize some labels.
> > I was trying to give this some thought but I have to admit I copped out
> > because of my limited knowledge on what labels would be reasonable to
> > reserve.
> >
> > Based on what you mention, do you think the list bellow would make sense?
> >
> > #define IFAPROT_UNSPEC 0 /* unspecified */
> > #define IFAPROT_KERNEL_LO 1 /* loopback */
> > #define IFAPROT_KERNEL_RA 2 /* auto assigned by kernel from router announcement */
> > #define IFAPROT_KERNEL_LL 3 /* link-local set by kernel */
>
> Those above look good to me.
>
> > #define IFAPROT_STATIC 4 /* set by admin */
> > #define IFAPROT_AUTO 5 /* DHCP, BOOTP etc. */
> > #define IFAPROT_LL 6 /* link-local set by userspace */
> >
> > Or do you think it needs more granularity?
>
> anything coming from userspace can just be a passthrough, so protocol
> label is only set if it is an autonomous action by the kernel or some
> app passed in a value.
>
Thanks David, that makes sense. Will include the first defines in v2
and try to set them when appropriate.
Powered by blists - more mailing lists