[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK-6q+gtcDVCGB0KvhMjQ-WotWuyL7mpw99-36j_TcC7mc2qyA@mail.gmail.com>
Date: Thu, 1 Sep 2022 22:48:10 -0400
From: Alexander Aring <aahringo@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Leon Romanovsky <leon@...nel.org>,
Stefan Schmidt <stefan@...enfreihafen.org>,
Alexander Aring <alex.aring@...il.com>,
Gal Pressman <gal@...dia.com>,
"David S. Miller" <davem@...emloft.net>,
Network Development <netdev@...r.kernel.org>,
linux-wpan - ML <linux-wpan@...r.kernel.org>
Subject: Re: [PATCH net-next] net: ieee802154: Fix compilation error when
CONFIG_IEEE802154_NL802154_EXPERIMENTAL is disabled
Hi,
On Thu, Sep 1, 2022 at 4:23 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Thu, 1 Sep 2022 09:38:35 +0300 Leon Romanovsky wrote:
> > There is no such thing like experimental UAPI. Once you put something
> > in UAPI headers and/or allowed users to issue calls from userspace
> > to kernel, they can use it. We don't control how users compile their
> > kernels.
> >
> > So it is not break "experimental commands", but break commands that
> > maybe shouldn't exist in first place.
> >
> > nl802154 code suffers from two basic mistakes:
> > 1. User visible defines are not part of UAPI headers. For example,
> > include/net/nl802154.h should be in include/uapi/net/....
> > 2. Used Kconfig option for pseudo-UAPI header.
> >
> > In this specific case, I checked that Fedora didn't enable this
> > CONFIG_IEEE802154_NL802154_EXPERIMENTAL knob, but someone needs
> > to check debian and other distros too.
> >
> > Most likely it is not used at all.
>
> You're right, FWIW. I didn't want to get sidetracked into that before
> we fix the immediate build issue. It's not the only family playing uAPI
> games :(
>
I am not sure how to proceed here now, if removing the
CONFIG_IEEE802154_NL802154_EXPERIMENTAL option is the way to go. Then
do it?
It was a mistake to introduce that whole thing and a probably better
way is to change nl802154 is to mark it deprecated, after a while
rename the enum value to some reserved value and remove the associated
code. Then after some time it can be reused again? If this sounds like
a better idea how to handle the use case we have here?
I am sorry that this config currently causes such a big problem here.
- Alex
Powered by blists - more mailing lists