[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+yOsYSRSZV1kwpq@nanopsycho>
Date: Wed, 15 Feb 2023 08:50:09 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: Jakub Kicinski <kuba@...nel.org>, 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
Wed, Feb 15, 2023 at 12:05:23AM CET, jhs@...atatu.com wrote:
>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.
Guys. I don't think that matters. There might be some non-public code
using this headers and we don't want to break them either. I believe we
have to stick with it. But perhaps we can include some note there.
>
>cheers,
>jamal
Powered by blists - more mailing lists