Messages in this thread | | | Subject | Policy for reverting user ABI breaking patches was Re: RFC: Starting a stable kernel series off the 2.6 kernel | From | Andi Kleen <> | Date | 06 Dec 2005 15:50:55 -0700 |
| |
Greg KH <greg@kroah.com> writes:
> > And there will always be a need for new package upgrades for some small > subset of programs that are tightly tied to the kernel (like > wpa_supplicant or alsa-libs, or even udev). But "normal" userspace
Actually I don't necessarily agree on that. It's best to avoid breakage even for them. It has actually worked for a long time. In the early days of Linux there was frequent breakage like this but then in recent times the kernel has been very good at this for a long time (one exception was the module rewrite, but that was a single flag day). I have been running modern kernels on old distributions for a long time and it generally worked.
And if there is breakage of such kernel-near applications there should be an *extremly* good reason for this (and minor cleanup isn't such a reason). For example for the recent udev breakage imho the cleanup patch that caused this should have just been reverted. I know it's not possible to know such bad interactions in advance, but when they are known and there isn't an *extremly* good reason for it then the ABI breaking change should be reverted.
It would be good to have a policy like this: if an important program breaks due to a new kernel
[With important being fairly liberally defined as anything shipped in standard distros unless it's something exotic that does something stupid or is obviously broken. External kernel modules or /dev/mem access don't count.]
then the breakage needs to have an *extremly* good rationale (fixing security bugs etc.) and if there isn't one from the person who submitted the patch then it should be reverted.
-Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |