Was: Problems with bridging on Sparc64

Was: Problems with bridging on Sparc64

[C.Newport]

On Tuesday 03 February 2004 12:37 pm, Small, Jim wrote:
> David,
>
> Please excuse my ignorance, but is there an easy way to build the bridging
> tools/library as 64bit binaries or are you saying that the dependence on
> SIOCDEVPRIVATE makes it extremely difficult without redesigning the
> bridging software?

As a slight aside, do we have any standards in place for the migration
to 64 bit ?. So far we have :-

a) 64 bit kernel should be standard for Ultras by now in all distributions.
b) A small number of applications such as the above NEED to be
    compiled for 32 or 64 bit.
c) Most 32 bit applications are OK on 64 bit kernels and there is no
    advantage in compiling as 64 bit.
d) Some applications would benefit from having a 64 bit version.

With more systems (especially X86) becoming 64 bit capable we
could be heading for a horrid mess with each distribution doing
incompatible things.

My suggestion if no standards exist :-
The installer should put 64 bit apps in /bin64 and make a symlink
from /bin or /sbin only if the machine supports 64 bit.
It is probably a bad idea to have such applications under /usr 
because /usr should be capable of being NFS shared RO by multiple
machines.

What does the team think ?

Re: Was: Problems with bridging on Sparc64

[Ben Collins]

> What does the team think ?

I think you have no clue about the intracacies of managing a
distribution. Debian's already started dealing with this. None of it has
to do with compatibility with other dists. It's all package management,
and it's all dist specific.

About the only standard is /lib64:/usr/lib64 for libraries.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: Was: Problems with bridging on Sparc64

[Ben Collins]

> We should take pity on the developer of some nice 64 bit application 
> who tries to get his install scripts to work on all common Linux 
> distributions. Portability between distributions is a major headache
> for application developers.


With Debian, I think the goal is to make dpkg recognize the ABI aswell
as the arch.  The binaries will go in standard places (/bin, etc..).
Packages that support this will have ABI independent files go in a
seperate package (config files, headers, gifs, etc...) if needed, and
supply binary packages that are built for each ABI (sparc32, v9,
sparc64, etc..same goes for x86, x86-64 and hppa/hppa64).

So you would not be able to install, say bridge-utils for the 32-bit ABI
and bridge-utils for the 64-bit ABI together. They would conflict with
each other. You will however be able to install libc6 for 32-bit and
64-bit ABI's simultaneously.

This hasn't been done yet, but as more and more architectures hit this
problem, more and more folks are working on it.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: Was: Problems with bridging on Sparc64

[C.Newport]

On Tuesday 03 February 2004 8:18 pm, Ben Collins wrote:
> > What does the team think ?
>
> I think you have no clue about the intracacies of managing a
> distribution. Debian's already started dealing with this. None of it has
> to do with compatibility with other dists. It's all package management,
> and it's all dist specific.
>
> About the only standard is /lib64:/usr/lib64 for libraries.

Not completely ignorant <B-).
I am currently working on the next release of the Splack installer
so I am trying to think ahead. The Splack 8.0 installer was a 
learning experience, this one is a chance to do better.
I am a bit constrained by the policy of retaining the
Slackware look and feel, but the Sparc stuff is far less simple
than X86 with  $ARCH kernel variants to worry about as well as
needing to support tftp installs and diskless Javastations.

It would be nice to have some form of standardisation in where 64 bit
things finally end up after the install, most Linux distributions seem
to put most things in fairly standard places but I am concerned that
the migration to 64 bit is likely to be chaotic unless some de-facto
standards are in place. 

We should take pity on the developer of some nice 64 bit application 
who tries to get his install scripts to work on all common Linux 
distributions. Portability between distributions is a major headache
for application developers.

Re: Was: Problems with bridging on Sparc64

[C.Newport]

On Tuesday 03 February 2004 9:21 pm, Ben Collins wrote:
> > We should take pity on the developer of some nice 64 bit application
> > who tries to get his install scripts to work on all common Linux
> > distributions. Portability between distributions is a major headache
> > for application developers.
>
> With Debian, I think the goal is to make dpkg recognize the ABI aswell
> as the arch.  The binaries will go in standard places (/bin, etc..).
> Packages that support this will have ABI independent files go in a
> seperate package (config files, headers, gifs, etc...) if needed, and
> supply binary packages that are built for each ABI (sparc32, v9,
> sparc64, etc..same goes for x86, x86-64 and hppa/hppa64).

Thanks, the Debian method makes a lot of sense.
BTW, you have just reminded me of another issue :-

You mention both sparc v9 and sparc64. 
AIUI v9 is the Sun Ultrasparc and sparc64 is the slightly different
Fujitsu processor. We seem to refer to both under the confusing
sparc64 header, but I do not see much testing happening on Fujitsu
stuff. Am I misunderstanding the situation or should we consider
getting the naming sorted out ?.
Does anyone even have a Sparc64 (Fujitsu) machine working ?.

Re: Was: Problems with bridging on Sparc64

[Ben Collins]

On Tue, Feb 03, 2004 at 11:02:40PM +0000, C.Newport wrote:
> On Tuesday 03 February 2004 9:21 pm, Ben Collins wrote:
> > > We should take pity on the developer of some nice 64 bit application
> > > who tries to get his install scripts to work on all common Linux
> > > distributions. Portability between distributions is a major headache
> > > for application developers.
> >
> > With Debian, I think the goal is to make dpkg recognize the ABI aswell
> > as the arch.  The binaries will go in standard places (/bin, etc..).
> > Packages that support this will have ABI independent files go in a
> > seperate package (config files, headers, gifs, etc...) if needed, and
> > supply binary packages that are built for each ABI (sparc32, v9,
> > sparc64, etc..same goes for x86, x86-64 and hppa/hppa64).
> 
> Thanks, the Debian method makes a lot of sense.
> BTW, you have just reminded me of another issue :-
> 
> You mention both sparc v9 and sparc64. 
> AIUI v9 is the Sun Ultrasparc and sparc64 is the slightly different
> Fujitsu processor. We seem to refer to both under the confusing
> sparc64 header, but I do not see much testing happening on Fujitsu
> stuff. Am I misunderstanding the situation or should we consider
> getting the naming sorted out ?.
> Does anyone even have a Sparc64 (Fujitsu) machine working ?.

You are speaking in the wrong context. v9 is the standard sparc
instruction set (version 9) as described on sparc.com.

Sun calls their system UltraSPARC, and Fujitsu calls theirs SPARC64.

What I was talking about above was 32-bit applications geared toward v9
instruction set, which is not the same as 64-bit applications. It's an
optimization similar to the difference between -march=i486 and
-march=i686.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: Was: Problems with bridging on Sparc64

[David S. Miller]

On Tue, 3 Feb 2004 23:02:40 +0000
"C.Newport" <crn@netunix.com> wrote:

> You mention both sparc v9 and sparc64. 
> AIUI v9 is the Sun Ultrasparc and sparc64 is the slightly different
> Fujitsu processor. We seem to refer to both under the confusing
> sparc64 header, but I do not see much testing happening on Fujitsu
> stuff. Am I misunderstanding the situation or should we consider
> getting the naming sorted out ?.
> Does anyone even have a Sparc64 (Fujitsu) machine working ?.

When we speak of sparc64 we simply mean the 64-bit Sparc userland
ABI.  When we say v9 we mean sparc 32-bit ABI plus availability of
the Sparc v9 instructions.

Someone inside Fujitsu at some point got the most recent Fujitsu
chips working (they are very close, MMU/Cache programming wise,
to UltraSPARC unlike the initial fujistu 64-bit sparcs) but they
never submitted a final patch to me and all that stuff is pretty
dead these days anyways :)

Re: Was: Problems with bridging on Sparc64

[C.Newport]

On Tuesday 03 February 2004 11:20 pm, David S. Miller wrote:
> On Tue, 3 Feb 2004 23:02:40 +0000

> When we speak of sparc64 we simply mean the 64-bit Sparc userland
> ABI.  When we say v9 we mean sparc 32-bit ABI plus availability of
> the Sparc v9 instructions.

Hmmmm - Sparc64 is a registered trademark owned by Fujitsu.
Hopefully their lawyers are a little more forgiving than most. <B-).

Re: Was: Problems with bridging on Sparc64

[Baurjan Ismagulov]

Hello,

On Tue, Feb 03, 2004 at 04:21:39PM -0500, Ben Collins wrote:
> So you would not be able to install, say bridge-utils for the 32-bit ABI
> and bridge-utils for the 64-bit ABI together. They would conflict with
> each other.

So, there are no plans to support such kind of installation for NFS
clients (e.g., like proposed /bin64)? We plan to package both versions
where binaries are /usr/bin/prg32 and /usr/bin/prg64 and provide a
script /usr/bin/prg, which would check the architecture and run the best
version. However, it would be interesting to know how the others solve
this issue.

With kind regards,
Baurjan.

Re: Was: Problems with bridging on Sparc64

[Ben Collins]

On Wed, Feb 04, 2004 at 10:01:28AM +0200, Baurjan Ismagulov wrote:
> Hello,
> 
> On Tue, Feb 03, 2004 at 04:21:39PM -0500, Ben Collins wrote:
> > So you would not be able to install, say bridge-utils for the 32-bit ABI
> > and bridge-utils for the 64-bit ABI together. They would conflict with
> > each other.
> 
> So, there are no plans to support such kind of installation for NFS
> clients (e.g., like proposed /bin64)? We plan to package both versions
> where binaries are /usr/bin/prg32 and /usr/bin/prg64 and provide a
> script /usr/bin/prg, which would check the architecture and run the best
> version. However, it would be interesting to know how the others solve
> this issue.

I'm not really interested in that kind of setup, but you could do it
without too much problems.

It'd be more of a headache to do that in a distribution.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/