Re: PROPOSED: 32/64 bit coexistance

[Vulture <t.sippel-dau@ic.ac.uk>]

George Kraft IV wrote:
> 
> FHS & LSB teams,
> 
> IBM and SuSE has the following suggestion regarding 32/64bit coexistance.
> 
> George (gk4)

Looking at the discussion that arose from that there were a lot of 
suggestions of architecture emulators and operating system emulators
with associated directories. They are too many to list here, and even
then only manage to scratch the top of the iceberg of complexity.

Controlling and managing this complexity is what we are about, so it 
would be a good idea to see where it leads to when played through.

On "classic" Linux systems ("not big and powerful like Gnu, probably 
only ever runs on 386 ...") we currently have:

   386, 486, 586/K5-..., Pentium-Classic, Pentium-MMX, Pentium-Pro/Celeron,
     Pentium-III/Celeron, Pentium-4, K6/-II/-III, Athlon/Duron, Crusoe,
       Winchip-C6, Winchip-2A/-3, CyrixIII/C3

On top of that there are the machines without 387 and the 486sx, as well 
as SMP vs uniprocessor.

Thankfully all those are handled in the kernel, which means distributions 
ship with either 386 or "Pentium" (not sure whether classic os MMX) kernels,
and mostly expect the user to recompile the kernel to get it more specific.

Now we get two (presumed incompatible) extensions, the AMD x86-64 effort
and the Intel IA64, maybe some more. We also get alpha (running ia32 with
binary compiler, as DEC had the technology). 

Application vendors do not want to compile and support hundreds of different
builds. What we have to control complexity is a timeline. So lets see:

  today /*/lib is 32 bit i386, with floating point instructions
        /*/libia64 contains the libraries for applications which need them
        /*/libx86-64 contains the libraries for applications which need them
        /*lib32 -> lib if the admin has set the link.

        These systems are "native 32 bit"
        Existing 32-bit applications use libraries in /*/lib

  imminent /*/lib is 32 bit, with floating point instructions
        /*/lib64 contains the libraries for applications which need them
        /*/libx86-64 contains the libraries for applications which need them
        /*/lib32 -> lib

        These systems are "native 32 bit"
        32-bit applicatios are built for libraries in /*/lib32
        Newly built 32-bit can be installed on legacy systems
        only if the are links /*/lib32 -> lib
        Legacy applications install and run just fine

  later (2004, say)
        /*/lib is 64 bit, ia64 or x86-64, respectively
        /*/lib32 contains the libraries for applications which need them
        /*/libia64 -> lib or /*/libx86-64 -> lib

        These systems are "native ia64" or "native x86-64". 
        Recently built 32 applications (which use /*/lib32) will run
        Legacy 32 bit applications will NOT install (indeed foul up the 
        system if they install a 32-bit library in /lib) and not run.
        Legacy 64 bit applications built for libia64 etc. will install
        and run just fine. 

        Application builders will at this stage have to provide 
        separate builds, and use /lib/libia64 and /lib/libx86-64,
        or restrict themselves to a compatibilty mode where they only use 
        instructions available on both architectures, and use /lib

  finally (2006 or so)
        One hopes there is an emulator either in the kernel or as a 
        separate module, which maps non-native i386-extensions into
        a native mode. Obviously this is really bad for performance
        but may be OK wwhere not critical. This is similar to a 
        floating point emulator. Otherwise, a linker may be able to 
        handle libraries of variant architectures and fix up the right
        routines at runtime. Applications just use /*/lib. Nobody
        will want to run 32-bit legacy applications anyway
        N.B. anybody recently had difficulty with coff-applications not
        capable of running agains an elf-kernel ? quite) 

The proposal is different to George's (IBM+SuSE) one in that it demands
/*/lib32 -> /lib instead of /*/lib -> lib32, and in that it demands that:

   1.  Application builders of current applications change their builds
       to use /lib32 etc., instead of /lib NOW. Applications built for
       /lib are "legacy builds" on the day they are built.

   2.  System Managers (and distro builders) have to make a link NOW
       (/*lib32 -> /lib) so as to install (imminently) current applications 
       successfully.

   3.  We have to come to an agreement for names for current architectures
       as "alternatives" to unnamed implicits. Since there is no mix between
       sparc, ppc, i386, mips etc architectures, all could use a generic
       32 suffix, or could be specific (ia32, s-390-31, ppc32 ...)
 
In other words, we all have to take a little bit of pain early. I think
this is preferable leaving it for later. 

                                Thomas

*   Why not use metric units and get it right first time, every time ?
*
*   email: cmaae47 @ imperial.ac.uk
*   voice: +4420-7594-6912 (day)
*   fax:   +4420-7594-6958
*   snail: Thomas Sippel - Dau
*          Linux Services Manager
*          Customer Relations Group
*          Information and Communication Technology
*          Imperial College of Science, Technology and Medicine
*          Exhibition Road
*          Kensington SW7 2BX
*          Great Britain