Re: kernel structures in 2.0.29->2.0.30

Philip Blundell (pjb27@cam.ac.uk)
Sat, 26 Apr 1997 12:12:50 +0100 (BST)


On Sat, 26 Apr 1997, Maciej Stachowiak wrote:

> The goal isn't "not upgrading," it's being able to upgrade without
> breaking binary compatability for modules. In a stable series this
> deserves at least some consideration.

Indeed. One point that I don't think has come up here yet, and that I
think is significant, is that for a lot of people (including me) the
actual effort of typing "make" to build a new version of the driver is
trivial, _but_ the hassle of then having two or more incompatible versions
floating around can be a lot worse. Whereas with 2.1.x you can expect
everybody to be running a fairly recent kernel, I'd guess a lot of people
are still on 2.0.0 because that's what came on their CD and they've seen
no reason to upgrade.

We sell semi-turnkey systems, and often the sorts of customers who are
using binary module distributions don't know _how_ to compile a kernel.
If one of these people needs a new version of your driver, you either have
to work out which kernel they're running, find a machine your end that has
a compatible kernel, and build them the right module, or get your
technical support people to talk them through the business of upgrading to
the same kernel as you. Neither is a very appealing prospect.

Note that the "free software" argument doesn't make any difference here.
We don't ship binary drivers because the source is proprietary - the
kernel-side stuff is usually only a few tens of lines, and not very
exciting - but because the customer isn't interested in source, and
wouldn't know what to do with it if he had it.

Admittedly none of this is the end of the world, and there are probably
ways round it in most cases (eg shipping a prebuilt latest kernel as
well). But it's a pain. Breaking compatibility once is just about
bearable, and I daresay there were good reasons, but let's try very hard
not to do it again.

p.