kernel friends: what's your preferred strategy for announcing to users that you're deprecating a driver and plan to remove it soon?

@ajd Send an RFC patch series with a lot of removed lines, see how many people start screaming, then calm them down with a promise that the driver is going to stay for a few more releases, but then it will be removed unless someone else steps up. 😉

@ajd The strategy behind it is that there is some discussion on the mailing list which will be noticed and reported by @kernellogger and maybe Phoronix, so even non-developers become aware.

@ajd

sometimes I think playing some tricks with a new or changed config option might be a good idea, as then people that run oldconfig will notice it.

other times I think "introducing delays on driver load that get longer with every new version coupled with a warning in the log" could help, as people then will investigate.

But I'm pretty sure Linus would hate such games and yell at people that try them. 🥴

@ptesarik @kernellogger haha that is definitely a strategy! though the driver I am looking at removing is pretty niche (specialised hardware that costs >$5000, basically all enterprise or academic users) and I suspect they're not going to find out via Phoronix!

@kernellogger yes this what I've been discussing with @mpe. imho it would be nice if kbuild provided some explicit attribute we could add to label which would have standardised warning behaviour so that one does not have to think very hard about how to do it

@kernellogger @mpe I'm going to add a warning message on driver probe but I don't think my users need surprising trickery at runtime ;)

@ajd @kernellogger Yes, the details depend on the specific driver. Some drivers would be quite hard to remove (think e.g. virtio-blk), but it's always worth a try.

Make kernel small again! #mksa

@ajd @kernellogger @mpe That implies that you actually have users of the driver. If so, why delete it?

@ajd @ptesarik @kernellogger Don't bet on how many people bought them on eBay 🙂
Anyway, I guess supposed to start with Documenation/process/deprecated.rst ?
Then some distros would drop it from new releases.

@penguin42 @kernellogger I believe @ajd asked about a “plan to remove it soon”. The official process takes four to five years, which I assumed was NOT soon.

@ajd I become a living meme about it on fediverse.

@ptesarik @kernellogger @ajd Well there's no reason to rush to actually remove code; mark it deprecated and then laugh evilly at anyone who asks why it's broken.

@penguin42 @kernellogger @ajd Good, then the deprecation process works fine. You may not even have to remove the code. If you're lucky, it will be deleted by @gregkh to solve a CVE.

@penguin42 @ptesarik @kernellogger that process seems to be focused on internal APIs, rather than drivers

@gregkh @kernellogger @mpe I strongly suspect there are ~0 users who will be impacted by the removal of this driver from upstream by the time I eventually get around to ripping everything out. my confidence not being 100% I'd like to responsibly warn people

@gregkh @kernellogger @ajd As far as we know there are no users - all the usual signals are blank (eg. bug reports etc.) @ajd also checked via IBM channels and got no signs of life. The driver has hooks into core arch code, so it's not the kind of driver we can maintain indefinitely at zero cost. But we don't want to just tear it out, on the off chance there is some user somewhere we don't know about.

@llvm @gregkh @kernellogger @ajd Some do, I count ~50 with a quick grep. media especially seems to do it. I don't really see the point though, because it's not user-visible, so the eventual removal can still come as a shock to users.

@llvm @mpe @kernellogger @ajd That's not what staging is for (we tried it.) Just delete the driver and if someone shows up who uses it, revert the delete and all is good.