[Linux-ia64] PROPOSED: 32/64 bit coexistance

[Linux-ia64] PROPOSED: 32/64 bit coexistance

[Doug Beattie]

Your reponse is welcome and invited.

The LSB and FHS groups are trying to better address the coexistance of
32 and 64 bit in the 64 bit Itanium environment.

Please review the following proposal and respond to the
"lsb-spec@lists.linuxbase.org" and "lsb-discuss@lists.linuxbase.org"
mail lists.

Thanks,
Doug

George Kraft IV wrote:
> 
> FHS & LSB teams,
> 
> IBM and SuSE has the following suggestion regarding 32/64bit coexistance.
> 
> George (gk4)
> 
> > > 32/64bit executable coexistence
> > >
> > > 32/64bit executable coexistence on architectures with 32/64bit
> > > backward compatibility
> > >
> > > Introduction
> > >
> > > Linux has been ported to serveral different architectures and is
> > > now available for both 32bit and 64bit processors. Some of these
> > > architectures and their implementations in hardware already allow
> > > or will allow parallel execution of 32bit and 64bit applications
> > > in the very same single operating system instance.
> > >
> > > As the 32bit and 64bit instances of libraries like glibc usually
> > > are named identically due to the same source code base, they
> > > cannot reside in the same directory of the Linux file system
> > > hierarchy.
> > >
> > > There is a decision to be made about the location and naming
> > > conventions for the dedicated libraries, if backward
> > > compatibility of existing 32bit applications on 64bit systems is
> > > desired.
> > >
> > > Discussion
> > >
> > > Until now two significant 64bit Linux ports are available using a
> > > 64bit kernel and 64bit userland: Compaq Alpha and Intel Itanium
> > > based systems. Theses ports fully exploit the 64bit architecure;
> > > nevertheless they are able to run 32bit code, too.
> > >
> > > The new emerging or potential ports for AMD x86-64, IBM pSeries /
> > > iSeries Power3/4, SPARC32/64 and IBM zSeries approach the 64bit
> > > area in different ways:
> > >
> > > - AMD x86-64 can be regarded as transparently extending the 32bit
> > >   architecture by 64bit features
> > >
> > > - ipSeries today only have 32bit based kernels and userland
> > >   available, but are expected to have 64bit kernel in the near
> > >   future (same as x86-64)
> > >
> > > - SPARC runs 64bit and 32bit based kernels, userland is mostly
> > >   32bit based, with 64bit based libs available, too (same as
> > >   x86-64, ipSeries)
> > >
> > > - S/390 and zSeries can be supported in either way: S/390 by
> > >   31/32bit kernel and userland, zSeries with 64bit kernel and
> > >   32bit and 64 bit userland executables.
> > >
> > > Applications can be build either using 32bit or 64bit and are
> > > usually compiled to use dedicated shared libraries of each type.
> > > If one application runs in 64bit, it can only use 64bit
> > > libraries. The same applies for 32bit. There's no way to use both
> > > 32-bit and 64-bit libraries in one application.
> > >
> > > Loading the depending functions and libraries is done during
> > > execution by the dynamic loader. It needs to know dedicated file
> > > system pathes to search for available libraries.
> > >
> > > 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. 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.
> > > [...]
> > >
> > > 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 been implemented this way).
> > >
> > > 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. This is clearly not an issue for the loader, that will
> > > be able to properly select the library to load from, but will be an
> > > issue for all existing 32bit applications and their install scripts
> > > and the like, not knowing about the hybrid nature of a 32/64bit
> > > system environment. Thus we're suggesting that /lib is always a
> > > symbolic link to /lib32 to grant backward compatibility and new 64bit
> > > applications to use and install into /lib64.
> 
> --
> George Kraft IV
> gk4@austin.ibm.com

-- 
Douglas B. Beattie
------------------
Linux Test Architect - Caldera, Inc.
dbb@caldera.com

Re: [Linux-ia64] PROPOSED: 32/64 bit coexistance

[David Mosberger]

>>>>> On Mon, 17 Sep 2001 10:02:14 -0600, Doug Beattie <dbb@caldera.com> said:

  Doug> Your reponse is welcome and invited.  The LSB and FHS groups
  Doug> are trying to better address the coexistance of 32 and 64 bit
  Doug> in the 64 bit Itanium environment.

  Doug> Please review the following proposal and respond to the
  Doug> "lsb-spec@lists.linuxbase.org" and
  Doug> "lsb-discuss@lists.linuxbase.org" mail lists.

When will people learn that for Linux, source compatibility is just as
important as binary compatibility?  For IA-64 Linux, the decision was
made that native libraries go into /lib etc and that legacy libraries
go somewhere else (/usr/i386-*-linux/lib, commonly).

	--david

Re: [Linux-ia64] PROPOSED: 32/64 bit coexistance

[Jes Sorensen]

>>>>> "David" = David Mosberger <davidm@hpl.hp.com> writes:

>>>>> On Mon, 17 Sep 2001 10:02:14 -0600, Doug Beattie <dbb@caldera.com> said:
Doug> Your reponse is welcome and invited.  The LSB and FHS groups are
Doug> trying to better address the coexistance of 32 and 64 bit in the
Doug> 64 bit Itanium environment.

Doug> Please review the following proposal and respond to the
Doug> "lsb-spec@lists.linuxbase.org" and
Doug> "lsb-discuss@lists.linuxbase.org" mail lists.

David> When will people learn that for Linux, source compatibility is
David> just as important as binary compatibility?  For IA-64 Linux,
David> the decision was made that native libraries go into /lib etc
David> and that legacy libraries go somewhere else
David> (/usr/i386-*-linux/lib, commonly).

Not to mention that ld.so has already been fixed to handle searching
through library directories containing libraries for a different
architecture than ld.so is running on itself. Hence the whole point of
ia32 binaries being unable to cope with ia64 binaries in /lib is
completely useless.

It would have been extremely nice if the people who decided to write
this standard had started out by asking the people who did the
implementation work how the architecture really works and what
experience has been gained in these areas already.

Jes

Re: [Linux-ia64] PROPOSED: 32/64 bit coexistance

[Lenz Grimmer]

On 18 Sep 2001, Jes Sorensen wrote:

> >>>>> "David" = David Mosberger <davidm@hpl.hp.com> writes:
>
> >>>>> On Mon, 17 Sep 2001 10:02:14 -0600, Doug Beattie <dbb@caldera.com> said:
> Doug> Your reponse is welcome and invited.  The LSB and FHS groups are
> Doug> trying to better address the coexistance of 32 and 64 bit in the
> Doug> 64 bit Itanium environment.
>
> Doug> Please review the following proposal and respond to the
> Doug> "lsb-spec@lists.linuxbase.org" and
> Doug> "lsb-discuss@lists.linuxbase.org" mail lists.
>
> David> When will people learn that for Linux, source compatibility is
> David> just as important as binary compatibility?  For IA-64 Linux,
> David> the decision was made that native libraries go into /lib etc
> David> and that legacy libraries go somewhere else
> David> (/usr/i386-*-linux/lib, commonly).
>
> Not to mention that ld.so has already been fixed to handle searching
> through library directories containing libraries for a different
> architecture than ld.so is running on itself. Hence the whole point of
> ia32 binaries being unable to cope with ia64 binaries in /lib is
> completely useless.
>
> It would have been extremely nice if the people who decided to write
> this standard had started out by asking the people who did the
> implementation work how the architecture really works and what
> experience has been gained in these areas already.

Who said, that this is already a "standard"? It's a proposal and you are
welcome to comment on it. It seems like everybody is aware of the problem
- this documents simply attempt to make sure, that we all play on the same
sheet of music and avoid yet another difference between implementations.

Bye,
	LenZ
-- 
------------------------------------------------------------------
 Lenz Grimmer                                           SuSE GmbH
 mailto:grimmer@suse.de                       Schanzaeckerstr. 10
 http://www.suse.de/~grimmer/            90443 Nuernberg, Germany
                 The trodden path is the safest.

Re: [Linux-ia64] PROPOSED: 32/64 bit coexistance

[Andreas Jaeger]

Jes Sorensen <jes@sunsite.dk> writes:

>>>>>> "David" = David Mosberger <davidm@hpl.hp.com> writes:
>
>>>>>> On Mon, 17 Sep 2001 10:02:14 -0600, Doug Beattie <dbb@caldera.com> said:
> Doug> Your reponse is welcome and invited.  The LSB and FHS groups are
> Doug> trying to better address the coexistance of 32 and 64 bit in the
> Doug> 64 bit Itanium environment.
>
> Doug> Please review the following proposal and respond to the
> Doug> "lsb-spec@lists.linuxbase.org" and
> Doug> "lsb-discuss@lists.linuxbase.org" mail lists.
>
> David> When will people learn that for Linux, source compatibility is
> David> just as important as binary compatibility?  For IA-64 Linux,
> David> the decision was made that native libraries go into /lib etc
> David> and that legacy libraries go somewhere else
> David> (/usr/i386-*-linux/lib, commonly).
>
> Not to mention that ld.so has already been fixed to handle searching
> through library directories containing libraries for a different
> architecture than ld.so is running on itself. Hence the whole point of
> ia32 binaries being unable to cope with ia64 binaries in /lib is
> completely useless.
>
> It would have been extremely nice if the people who decided to write
> this standard had started out by asking the people who did the
> implementation work how the architecture really works and what
> experience has been gained in these areas already.

Please read the email that I've send some minutes, George forgot to
append one paragraph.  We didn't want to suggest that ia64 was changed
- the purpose was to unify existing practice and decide on a way how
to handle it with newer 64 bit platforms that have a mixed 32-bit and
64-bit userland.

For ia64 the situation is a bit different than for PPC64, S390, x86-64
and MIPS.

Andreas

-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: [Linux-ia64] PROPOSED: 32/64 bit coexistance

[Ulrich Drepper]

Jes Sorensen <jes@sunsite.dk> writes:

> It would have been extremely nice if the people who decided to write
> this standard had started out by asking the people who did the
> implementation work how the architecture really works and what
> experience has been gained in these areas already.

Well, this is not fair.  I have been there when the spec was written.
At that time it was not yet decided how Linux would handle this.  It
was strongly felt by all the Unix people that the way it is specified
things should be implemented.  When the decisions for Linux were made
and they conflicted nothing happened to rectify the problem.

It's just that we have more liberties and can do things right while
the Unix vendors feel they must pay attention to l^Husers using IA-32
binaries.  It's there problem if they want to make the life of
programmers and sysadmins harder.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------