[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM0EoM=gOFgSufjrX=+Qwe6x9KN=PkBaDLBZqxeKDktCy=R=sw@mail.gmail.com>
Date: Tue, 14 Feb 2023 18:05:23 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
xiyou.wangcong@...il.com, davem@...emloft.net, edumazet@...gle.com,
pabeni@...hat.com, stephen@...workplumber.org, dsahern@...il.com
Subject: Re: [PATCH net-next 0/5] net/sched: Retire some tc qdiscs and classifiers
On Tue, Feb 14, 2023 at 4:41 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Tue, 14 Feb 2023 13:40:13 -0800 Jakub Kicinski wrote:
> > > I think we have to let the UAPI there to rot in order not to break
> > > compilation of apps that use those (no relation to iproute2).
> >
> > Yeah, I was hoping there's no other users but this is the first match
> > on GitHub:
> >
> > https://github.com/t2mune/nield/blob/0c0848d1d1e6c006185465ee96aeb5a13a1589e6/src/tcmsg_qdisc_dsmark.c
> >
> > :(
>
> I mean that in the context of deleting the uAPI, not the support,
> to be clear.
Looking at that code - the user is keeping their own copy of the uapi
and listening to generated events from the kernel.
With new kernels those events will never come, so they wont be able to
print them. IOW, there's no dependency on the uapi being in the kernel
- but maybe worth keeping.
Note, even if they were to send queries - they will just get a failure back.
cheers,
jamal
Powered by blists - more mailing lists