Hi, On Thu, Sep 1, 2022 at 4:23 PM Jakub Kicinski <kuba@xxxxxxxxxx> 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
