On Fri, 5 Mar 2010, Daniel Stone wrote:
>
> So you're saying that there's no way to develop any reasonable body of
> code for the Linux kernel without committing to keeping your ABI
> absolutely rock-solid stable for eternity, no exceptions, ever?
I think that's what David ended up saying, but I think he is being _too_
strict.
It's not how we've done other things either. We've changed ABI's over time
many times. And we've even had complete breakage of old tools (although
that is very much reserved for system tools, not regular applications: I
think we've been almost religious about "normal" apps not breaking,
unless there was some really overriding reason like security that forced
us to really remove some interface).
But most of the changes have been extending things, leaving the old
interfaces around (often as wrappers around the new internal world order,
sometimes by effectively having actual duplicated code).
And then the old interface is maintained for quite a while (sometimes
decades, often years, and generally at least for several kernel versions
so that people have time to upgrade, and a distro can generally pick a
newer kernel without having to change anything else).
Sometimes we've done things that really end up requiring new tools. It's
pretty rare, but it does happen. It happens a lot more for "esoteric"
things that aren't every-day-in-your-face (I've seen at least _one_ mutter
about "sysfs" in this thread ;) and might break something like a
temperature sensor, for example.
So the machine might _work_ and you could go for days without even
noticing, but you might have some very specific functionality missing.
Maybe your power meter doesn't work, or maybe you need to upgrade your
kernel profiler to get good profiles again. Things like that.
I suspect you as an X person know this very well, in fact. X itself has
carried along a _lot_ of cruft exactly like this, that you guys have been
removing only in the last few years - sometimes after decades of it being
there. The whole switch to modern font handling is an obvious example of a
_major_ fundamental feature change like that.
So in general, what the kernel strives for is that very kind of "the old
model will still work - but it might be slow and emulated on top of a new
way of dong things, and not get a lot of attention any more".
And sometimes, there's really no good way of maintaining two interfaces at
the kernel level, and then you have the downstream tools that have to
learn to pick either the old or the new one, so that the tool still works
regardless.
And again, the old code _eventually_ bitrots or gets cleaned up, but what
you really really want to avoid is to have a flag-day when you switch from
one to the other, and you can't switch between adjacent versions of the
kernel.
In the 2.4.x/2.6.x split, for example, we did have system tools that
needed to be upgraded if you came from a 2.4.x environment. You can still
see signs of that in the kernel tree: we have that whole
Documentation/Changes file that _still_ remains in our tree, even though
it's purely historical.
But if you look at that Documentation/Changes file, I don't think there is
_any_ flag-day issue except for the removal of "devfs". People _still_
talk about devfs in hushed tones. Everything else is about having to
upgrade system tools _before_ upgrading the kernel (iow, they still worked
on 2.4.x, but you needed recent enough versions of them to compile and run
a 2.6.x kernel).
In other words, it wasn't a "flag day" (apart from the already mentioned
devfs users, and possibly something else I can't think of). It was an
upgrade, yes, and it required some other things to be recent, but you
could go back-and-forth between kernels if you had to.
(Of course, it's now many years since that, so maybe my rose-colored
glasses makes me forget the pain involved. And I obviously personally
never made the whole 2.4.x -> 2.6.x jump, since I'd been running the
development kernels in between. So maybe I forgot some painful part).
Linus
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
