On Thu, Aug 13, 2015 at 4:05 PM, Linus TorvaldsIs there a way to temporally confine the bad crap code just to the applications that depend on it, or does a userspace app latching onto bad behavior effectively lock down the abi for the future?
The _only_ thing that matters is that something broke.To clarify: things like test programs etc don't matter. Real
applications, used by real users. That's what regressions cover. If
you have a workflow that isn't just some random kernel test thing, and
you depend on it, and we break it, the kernel is supposed to fix it.
There are some (very few) exceptions.
If it's a security issue, we may not be able to "fix" it, because
other concerns can obviously take precedence.
Also, sometimes the reports come in way too late - if you were running
some stable distro kernel for several years, and updated, and notice a
change that happened four years ago and modern applications now rely
on the _new_ behavior, we may not be able to fix the regression any
But no, "it was an unintentional kernel bug and clearly just stupid
crap code, and we fixed it and now the kernel is much better and
cleaner" is not a valid reason for regressions. We'll go back to the
stupid and crap code if necessary, however much that may annoy us.
For an example of the kind of things we may have to do, see commits
64f371bc3107 autofs: make the autofsv5 packet file descriptor use
a packetized pipe
9883035ae7ed pipes: add a "packetized pipe" mode for writing
and just wonder at the insanity. That's the kinds of things that
happen when one application had actively worked around a bug in
compatibility handling, and then trying to "fix" that bug just caused
another application to break instead.