ajdkernel friends: what's your preferred strategy for announcing to users that you're deprecating a driver and plan to remove it soon?
Petr Tesarik@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.
@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!
@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
penguin42@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.
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.
@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
Thorsten Leemhuis (acct. 1/4)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. 🥴
@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 ;)
Greg K-H@ajd @kernellogger @mpe That implies that you actually have users of the driver. If so, why delete it?
@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
mpe@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.
vbabka@ajd I become a living meme about it on fediverse.