AMD64 Linux documentation

[Gene C.]

On Thursday 11 December 2003 18:53, Jeremy Katz wrote:
> On Thu, 2003-12-11 at 18:47, Gene C. wrote:
> > Not surprised about the G5 or the Power4.  However, the AMD64 is the only
> > architecture that Red Hat currently is trying to support dual
> > architecture under a single OS (If you ignore the i386/i586/i686/athlon
> > support).  The problem is that with the AMD64 you want most of the
> > packages in the distribution to be 64 bit with support to run other
> > (user) 32 bit applications.
>
> Incorrect, we do similar on zSeries (s390x is 64-bit with 31-bit
> compatibility) and i/pSeries (userspace is mostly 32-bit with some
> 64-bit compatibility at present) in Red Hat Enterprise Linux.

Thanks for the info/correction Jeremy!

Having dealt with IBM mainframes for years, I can well understand that the 
zSeries hardware supports both 64-bit and 31-bit addressing (and probably 
24-bit addressing as well).  However, not having seen the distribution media, 
I am not familiar with the amount of dual packages (s390x and s390) exist in 
the distribution -- the development directory trees for s390 and s390x only 
contrain their respective packages).

I have examined a number of the packages in the AMD64 taroon (which I 
downloaded previously ... I don't want to waste bandwidth downloading the FC 
preview until I am closer to having hardware ... maybe the test1 ISO images 
will be available by then).  Anyway, after examining the taroon packages, I 
am puzzled by some things:

1. I can see that having /lib - /lib64 and /usr/lib - /usr/lib64 resolves a 
lot of problems of coexistence.

2.  I understand that the /etc and /usr/share files do not likely matter since 
they will be most likely identical.  However, won't rpm still complain since 
you already have the package installed even if for a different architecture 
(ix86 vice x86_64) ... and if not about the package then about the duplicate 
files?  Somehow, using --force does not seem to be a good solution since it 
overrides and lot of safety checking.

3. I see a lot of packages with /sbin, /usr/sbin, and /usr/bin files 
(programs).  Depending on which package gets installed last will depend on 
which architecture's program gets installed.  Now, I well believe that this 
might be "controlable" during the anaconda install process with some hacks, 
but how about post install updating?

4. If it was only a couple of packages like glibc, maybe you could split the 
packages of something.  But it is not ... at least it does not appear to be 
just a few packages to me.

So how is this being resolved?  IMHO, the use of --force is not a good (let 
alone a long term) solution ... an I believe that coexistence of 32 bit and 
64 bit applications is a long term situation.

One thought that occurs to me is to use the --relocate capability of rpm to 
put stuff like /sbin into /sbin32.  Any thought given to that approach.

Any pointers to documentation/discussion of how to handle coexistence of dual 
architecture would be appreciated.  I have searched/browsed RedHat, Suse, and 
IBM sites and found nothing so far (goodness ... IBM must have 10 engineers 
creating hardware, 10 programmers creating software and 100,000 writers 
writing about it).

One additional thought/question ... OK, so you have /lib - /lib64 and /usr/lib 
- /usr/lib64 ... how does a program which needs a library get the "right" one 
since they are named the same?

This dual architecture support under a single OS looks tricky.  I am just 
trying to understand how this works.  Once I have real hardware and can 
install and play with it, perhaps it will become more obvious.
-- 
Gene