Policy for reverting user ABI breaking patches was Re: RFC: Starting a stable kernel series off the 2.6 kernel

[Andi Kleen]

Greg KH <greg@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/