Re: [tlug] Just curious... how much impact does a kernel update make?

["Ian Wells" <ijw@example.com>]

2008/11/17 Stephen J. Turnbull <stephen@example.com>:
> Ian Wells writes:
> There were significant differences between 2.4 and 2.6 before 2.*5*
> was even forked.  That is, Linus knew that there would be substantial
> ABI incompatibilities (GNU_MODULE or whatever the "I'm a GPL module"
> thingee is, for example) and reorganization of things like the kernel
> module hierarchy on disk.

True-ish, but there have been directory reorgs within 2.6 and speaking
from personal experience I can say that modules compilable and
runnable for one 2.6.x don't always compile or run on 2.6.y - so is
this 'significant'?

> That's sort of known a priori, isn't it?  What we've learned from 2.6
> is that the POSIX ABI plus Linux extensions already in 2.6 is flexible
> enough to accomodate those things efficiently without additional extension.

ioctl() is all things to all people - you can wrap almost any function
you care to write in ioctl().  Which implies that the kernel is nearly
infinitely extensible without ABI changes (for some carefully chosen
definition of ABI, which is another catch-all phrase, which we've
already used to describe module interfaces, system calls and ioctls
independent of system calls).

> Putting on my pointy Nostradamus cap with stars and moons and wizardly
> signs, I predict that Linux will go to 3.0 when the threading problem
> (ie, theoretically safe and pragmatically efficient use of shared
> state) gets solved.  I'm willing to bet that will involve new
> primitives, possibly including a new version of POSIX (or SUS if you
> prefer that terminology).

Of course, Nostradamus doesn't really have a record for reliability. ;-)

What I would wish for (I won't predict, since I'm not convinced that
kernel hackers themselves know what they're going to do from one day
to the next) is a kernel that is a lot smaller than the current
kernel.  There's risk in complexity, and the kernel has never shrunk
between versions.  It would make a lot of sense to try and reduce
complexity, in my opinion, even if this does break compatibility.

> amusing) suggests that it is *very* unlikely that POSIX has the tools
> to handle it, and Linux really is a very POSIX system.

POSIX-and-only-POSIX compatibility isn't something that's held people
back in the past.  Linux has non-POSIX stuff in any number of areas, I
don't see why one more would be a concern.

-- 
Ian.