Alternative to 64/32 hybrid - 32 bit UML

[Dan Shearer <dan@shearer.org>]

There was a discussion recently about whether or not to produce a hybrid
32/64-bit Opteron, and whether a pure 64-bit port would be useful,
especially if it shipped in time for Sarge.

There was some debate about whether it would be worth the time and
effort to do a 64-bit-only port for Sarge, given that a 32/64 solution
will be done eventually. I don't know too much about the policy changes
for the libraries to comment about the 32/64 issues from this point of
view. But I think there is a way of avoiding the problem entirely, at
least for Sarge.

If a 64-bit-only solution was to go ahead, a very workable 32-bit hybrid
can be provided without impacting library management at all. Just one
32-bit application is required, User Mode Linux (there is no 64-bit
version of UML yet anyway :-) This would solve the problem of getting an
Opteron port for Sarge without putting in major effort that will be
wasted.

Many platforms handle compatibility issues with wrapper systems or
emulation libraries with great success. The Alpha platform did this
years ago at several levels. All the commercial Unixes have emulation
systems for some part or other of their history, in more than one case
for 32-bit binaries. This is not a new approach I am suggesting,
although UML is neater and faster than any of the emulation technologies
I can think of now.

UML should be hardly noticeable as an emulation layer if packaged
correctly.  There are several ways that this can be handled, but since
everything inside UML is in its own little world there are no new
requirements for library management. At its most simplistic you can have
a magic number that runs a fresh instance of UML for every 32-bit binary
encountered with the required libraries tied to that instance, but
that's not general enough to be useful. At the other extreme is a
completely separate 32-bit distro inside UML with an external calling
mechanism that makes the existance of the second distro transparent. And
there are other options in-between, although with care this second
option could be made to work fairly efficiently.

-- 
Dan Shearer
dan@shearer.org