[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: PROPOSED: 32/64 bit coexistence

Andreas Jaeger wrote:
> What do you think?  Have we reached consensus - or where is still room
> for clarification?
>    The Linux File Hierarchy Standard FHS Version 2.2 final
>    (http://www.pathname.com/fhs/) supports both file location
>    and naming conventions for such libraries: /lib32 and /lib64
>    to place 32bit and 64bit libraries.

So far I was with you, but the names lib32 and lib64 are *examples*,
the FHS supports:

     /lib<qual> and /usr/lib<qual>

where the list of qualifiers is undefined.
>    Relevant paragraphs are: [...] 3.10.2 Requirements ->
>    footnote 12: This is commonly used for 64-bit or 32-bit
>    support on systems which support multiple binary formats,
>    but require libraries of the same name. In this case, /lib32
>    and /lib64 might be the library directories, and /lib a
>    symlink to one of them. [...]

The salient word is "might": a very weak "recommendation"

>    Note: FHS does not mention the case of one architecure being
>    capable different binaries like /libPPC or /libPPC64 (but
>    provides a naming convention scheme for it: /libNN)
>    On 'pure' 64bit systems the natural location would be /lib
>    for those libraries and 32bit libs would be placed in /lib32
>    (Linux for iA64, L/Alpha, and L/zSeries have started this
>    way).

A "pure" 64 bit system would surely be ILP64, by definititon an
int in C can be added to a pointer to obtain another pointer of
the same type. LP64 with 32 bit ints would not allow a program
address chars in a memory image of a file over 2 Gigabyte in size -
a DVD movie image, say.

This may not be a problem now, but in time it will be. For example, 
if you model air flow through a complete aero engine, 10 to 50 
Tb of memory (1 to 6 Terabytes) would certainly come in handy,
and addressing the points in the structure with 32 bit ints becomes 
>    While this naming conventions seems quite obvious and
>    natural it is not backward compatible: existing 32bit
>    applications will install and search their 32bit shared libs
>    in /lib which will only contain 64bit libs. A symbolic link
>    or renaming to /lib -> /lib32 will conflict with installed
>    64bit applications on the system.
> 3. Recommendations
>    We recommend the use of /lib64 to contain the 64bit
>    libraries on multi-library capable 64bit Linux ports and a
>    /lib which isn't a symbolic link but a real directory to
>    contain 32bit libraries for the following reasons:
>    * existing 32bit applications will install with rpm directly
>      and run without a change in a 64bit system (zSeries and
>      sparc64 today)

Fine for the time being, this is a "32 bit systemm with some 
64 bit capabilities"

This could run "Legacy 32 bit Applications" (which are linked 
against /lib meaning ILP32) and "32 bit Applications" (which 
are linked against /*/lib32 meaning ILP32), as well as "small 
model ia64 Applications compatible with 32 bit Environments" 
(meaning linked against /*/libia64 with ILP32") and "ia64
Applications for 32 bit Compatibility Environments" (meaning
linked against /*/libia64 with LP64).

>    * rpm is known to fail on nested symlinks within in pathes
>      on updating those directories; therefore /lib should not
>      be a link to /lib32.

Rpm could detect such a system by /lib32 being a link to /lib,
by inspecting releasee files etc..
>    * existing commercial binary-only applications like
>      middleware and applications are and might only be
>      available as 32-bit binaries for the time being due to
>      porting efforts and quality assurance cycles.

Yes, and they acquire the "Legacy" moniker. To loose that, they 
can start linking against /*/lib32 - a 5 minute "porting" effort.
>    * exisiting binary executable code generating tool chain
>      (gcc, binutils, glibc) already are capable to handle the
>      /lib64 approach
>    * /lib: consistent scheme for all 32bit systems and x86-64,
>      sparc64, ppc64, zSeries (s390x).
>    * iA64 today has a 32bit emulation mode, but 64bit is the
>      (only) favored one; Alpha is too long established. (64bit
>      libs will go to /lib)
>    * only few applications or middleware will benefit from full
>      64bit support in general (databases, ERP systems,
>      applications using large memory caches for speed, numeric
>      intense applications, ...)

This is true for a few years, same as "640 kilobytes ought to be 
enough for anybody", against which we should hold the (updated)
RMS statement: it is OK to use a Gigabyte memory, GNU will probably
not run on 32 bit systems anyway (see GNU coding standard for the
original ;-)

>    For emulation of other architectures, the FHS should be extended to
>    use the /emul/ prefix as /emul/<arch>-<opsys>, e.g. for an i386
>    Linux emulation the following directories would exist and follow
>    the filesystem layout conventions of the emulated environment:
>    /emul/i386-linux/lib
>    /emul/i386-linux/usr/lib

definitely not. At boot time a processor sort of knows what it is, and
the kernel mounts /, which later mount /usr for the bulky stuff.
What is wrong with /usr/lib/emul/<emulated architecture moniker>/
Then an application can just be linked against libraries in 
/usr/lib/emul/ia64 (say) and will run equally well on little-endian 
mips as on big-endian sparc machines. The only thing then needed
are the emulators ;-)

>    Preferred format of libraries, this is the format used for /lib:
>    Sparc64: ILP32

     Sparc -  with lib32 -> lib:  ILP32, with lib64 -> lib: LP64.
            just lib: ILP64 (and presumably 16 bit chars and 32 bit shorts)

>    x86-64:  ILP32

     ditto, mutatis mutandis, although AMD may be happy for some time
     with 32 bit pointers and longs for the "low cost" market

>    PPC64:   ILP32
>    s390x:   ILP32

Does  IBM really want to cap its processors at 32 bit longs and pointers ?
For the s390x this is probably OK, as the new stuff is now "zSeries", but
I still would not be sure.

>    MIPS64:  ILP32
>    Alpha:   LP64
>    ia64:    LP64

When Alpha came out in 1993 it was slanted as "with a growth path for 20 
years or more", we are now at the half-way stage, and it sort-of seems dead
in the water. But I am sure Intel will for its main processor want a way
to process objects bigger than 2 billion items in size, and that means ILP64.

Remember, Unix was addressing files with 32 bit offsets when a megabyte of
memory got you well past the mega$ computer price. We still use them at a 
time when scientific desktops with less than a gigabyte memory are "not 
economic to buy". We should look a little forward to a time when 2 gigabyte 
memeory modules carry a nuisance penalty the way 20 gigabyte disk drives 
do now.


*   Why not use metric units and get it right first time, every time ?
*   email: cmaae47 @ imperial.ac.uk
*   voice: +4420-7594-6912 (day)

Reply to: