4 ms·

https://lkml.org/lkml/2018/8/3/621 https://lkml.org/lkml/2018/8/3/621 > Yeah, HELL NO! Guess what? You're wrong. YOU ARE MISSING THE #1 KERNEL RULE. We do no

https://lkml.org/lkml/2018/8/3/621 https://lkml.org/lkml/2018/8/3/621 > Yeah, HELL NO! Guess what? You're wrong. YOU ARE MISSING THE #1 KERNEL RULE. We do not regress, and we do not regress exactly because your are 100% wrong. And the reason you state for your opinion is in fact exactly WHY you are wrong. Your "good reasons" are pure and utter garbage. The whole point of "we do not regress" is so that people can upgrade the kernel and never have to worry about it. -Linus Torvalds

mnd999 8y ago
Pretty sure that only applies to userland apps, not kernel modules.
joecot 8y ago
The linux kernel has made breaking changes [1] and deprecated APIs [2] internal APIs before. Specifically, your example brings up the danger that ZoL is in. The Linux kernel does everything in their power to not break User Land APIs. ZoL isn't User Land, and it replaced the previously extremely slow User Land ZFS Linux implementation. It is a Linux kernel module, and as [2] notes, Linux kernel devs are absolutely allowed to make breaking changes to internal APIs. The cost of the increased speed of a Kernel module is the risk of internal API breaking changes. I highly doubt that Linus would scream anywhere near as much about an internal API change that broke a separately maintained linux module with non-GPL code. 1. https://stackoverflow.com/questions/24897511/what-is-the-replacement-of-daemonize-kernal-api-in-3-x-kernel https://stackoverflow.com/questions/24897511/what-is-the-rep... 2. https://lwn.net/Articles/769365/ https://lwn.net/Articles/769365/
cryptonector 8y ago
That's about the ABI to user-land, not about internal-to-the-kernel interfaces.