Re: proposal to remove backward compatibility

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> We simply need to make the decision, and from that point forward,
>>> no more need for new compat code in the kernel.
>> No more ability to upgrade the kernel while running the previous
>> userland?
> If I had also installed a new libc [along with the kernel], then I
> would lose the ability to run the "old" system, [...]

This has finally crystallized for me why I consider "upgrade kernel and
libc" substantially worse than "upgrade kernel".  It's because it's
easy to boot with an alternative kernel; it is not easy to boot with an
alternative libc.

There are at least four ways to address this (and possibly more I
haven't thought of).

Way A is the way we've chosen so far - make the kernel provide ABI
compatability with the previous kernel (well, we've mostly chosen that;
we've broken it at least once I can name offhand, probably a few more
times I don't recall).

Way B is to provide some way to boot with an alternative libc.  The
easiest way to do this would probably be to move libc from the
filesystem into the kernel.  I hasten to add that I refer only to where
it's stored; I am not talking about moving libc to the privileged side
of the priv/unpriv boundary - the libc code would be loaded as part of
the kernel, but the kernel would export it to userland in a way that
lets userland call it without any kind of privilege mode switch.
(Another use for that user page we've been talking about for a while?)

Way C is to provide something like a /boot.conf that the kernel reads
at boot time and which we can use to, for example, fake up a symlink
for libc, pointing to the libc that goes with the kernel.

Way D is to do something like the magic symlinks NeXT's Mach did,
elaborated to the point where it can describe things like "this link
points to libc.`kernel compile timestamp`.so if that exists, otherwise
libc.so".

What do I think of them?  Well....

Way A, we all know and love/hate to varying degrees.

I'm not sure what I think of way B.  It hadn't occurred to me until I
started writing this email.  It would have a lot of implications for
other bits of the system, most of which I'm sure haven't occurred to me
yet.  But it might be worth at least thinking about; it certainly seems
like the most direct implementation of what Jason(?) said about moving
the compat promise from "kernel ABI" to "libc ABI".

Way C feels ugly and fragile to me.  I'd have to think about it more to
figure out why, but I tend to trust such feelings; when I've ignored
them, I've usually regretted it.

Way D feels like a solution in search of a problem.  To address this
desire, it would have to either have a severe special case or would
have to be way overkill.  I don't like either one.

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B