Linux GGI and Linux/SGI

Linux GGI and Linux/SGI

[John Wiederhirn]

Are there any plans to move (maybe it's already there) the
SGI version of Linux to a GGI-model design?
(see http://synergy.foo.net/~ggi/)


-- 
John Wiederhirn (DSD, Graphics Kernel MTS)        jwiede@engr.sgi.com
       "Smithers, unleash the human insight and creativity."

Re: Linux GGI and Linux/SGI

[Ralf Baechle]

> Are there any plans to move (maybe it's already there) the
> SGI version of Linux to a GGI-model design?
> (see http://synergy.foo.net/~ggi/)

Well, we have discussed using GGI.  Last I checkend GGI was still itself
in a state of flux and the last thing I want to do is to open another
battle field.  Technical reasons against GGI was mostly that the original
design was very bloated as far as the kernel is affected.  This has
been improoved somwhat since.

  Ralf

Re: Linux GGI and Linux/SGI

[Ralf Baechle]

> Are there any plans to move (maybe it's already there) the
> SGI version of Linux to a GGI-model design?
> (see http://synergy.foo.net/~ggi/)

Well, we have discussed using GGI.  Last I checkend GGI was still itself
in a state of flux and the last thing I want to do is to open another
battle field.  Technical reasons against GGI was mostly that the original
design was very bloated as far as the kernel is affected.  This has
been improoved somwhat since.

  Ralf

Re: Linux GGI and Linux/SGI

[John Wiederhirn]

On Aug 9, 12:20am, Ralf Baechle wrote:
>
> > Are there any plans to move (maybe it's already there) the
> > SGI version of Linux to a GGI-model design?
> > (see http://synergy.foo.net/~ggi/)
>
> Well, we have discussed using GGI.  Last I checkend GGI was still itself
> in a state of flux and the last thing I want to do is to open another
> battle field.  Technical reasons against GGI was mostly that the original
> design was very bloated as far as the kernel is affected.  This has
> been improoved somwhat since.

I'm not so attached to the notion of GGI as much as for gfx
having an in-kernel-space presence in Linux (Linux/SGI is
going to need this, as I suspect is any Linux that attempts
hardware acceleration of OpenGL or other similar APIs).

John

-- 
John Wiederhirn (DSD, Graphics Kernel MTS)        jwiede@engr.sgi.com
       "Smithers, unleash the human insight and creativity."

Re: Linux GGI and Linux/SGI

[Ralf Baechle]

> > Well, we have discussed using GGI.  Last I checkend GGI was still itself
> > in a state of flux and the last thing I want to do is to open another
> > battle field.  Technical reasons against GGI was mostly that the original
> > design was very bloated as far as the kernel is affected.  This has
> > been improoved somwhat since.
> 
> I'm not so attached to the notion of GGI as much as for gfx
> having an in-kernel-space presence in Linux (Linux/SGI is
> going to need this, as I suspect is any Linux that attempts
> hardware acceleration of OpenGL or other similar APIs).

Miguel "Da Newport Man" de Icaza is working on the required kernel stuff.
Since a real native GFX support is a fairly big project currently the
emulation stuff needed for the SGI X server has priority.

  Ralf

Re: Linux GGI and Linux/SGI

[Ralf Baechle]

> > Well, we have discussed using GGI.  Last I checkend GGI was still itself
> > in a state of flux and the last thing I want to do is to open another
> > battle field.  Technical reasons against GGI was mostly that the original
> > design was very bloated as far as the kernel is affected.  This has
> > been improoved somwhat since.
> 
> I'm not so attached to the notion of GGI as much as for gfx
> having an in-kernel-space presence in Linux (Linux/SGI is
> going to need this, as I suspect is any Linux that attempts
> hardware acceleration of OpenGL or other similar APIs).

Miguel "Da Newport Man" de Icaza is working on the required kernel stuff.
Since a real native GFX support is a fairly big project currently the
emulation stuff needed for the SGI X server has priority.

  Ralf

(no subject)

[Vincent Renardias]

	Hello,

	I've just joined this ML, and I'm trying to contribute to the
Linux/SGI development. Since I'm not too good at kernel hacking, I've
tough about working on porting the userland part (I have some experience
with this part since I've been a Debian developper for a while and
initiated the Debian/PowerPC port).
	By now I don't have access to any SGI hardware, but i've been able
to build some packages with the crossdev (i486-linux) packages from
ftp.linux.sgi.com.

	So here are my questions:

1/ Which are the 'most wanted' packages not yet recompiled/ported to
Linux/SGI? I've looked at the RPMs available RPM list, and some important
packages seem unavailable yet. (sed,tar,perl come to mind).

2/ While using the crossdev gcc, several times I got complains about a
file 'sgidefs.h' missing (from
/usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41). 
Commenting the '#include' file made the compile work, but I not sure it's
the right fix. 

3/ Can any1 confirm/correct the following values for GNU/autoconf:
ac_cv_c_bigendian=no
ac_cv_c_char_unsigned=no
ac_cv_sizeof_long=4
ac_cv_sizeof_int=4

	Cordialement,

--
-     ** Linux **         +-------------------+             ** WAW **     -
-  vincent@debian.org     | RENARDIAS Vincent |          vincent@waw.com  -
-  Debian/GNU Linux       +-------------------+      http://www.waw.com/  -
-  http://www.debian.org/           |            WAW  (33) 4 91 81 21 45  -
---------------------------------------------------------------------------

Re: your mail

[Ralf Baechle]

> 	I've just joined this ML, and I'm trying to contribute to the
> Linux/SGI development. Since I'm not too good at kernel hacking, I've
> tough about working on porting the userland part (I have some experience
> with this part since I've been a Debian developper for a while and
> initiated the Debian/PowerPC port).
> 	By now I don't have access to any SGI hardware, but i've been able
> to build some packages with the crossdev (i486-linux) packages from
> ftp.linux.sgi.com.
> 
> 	So here are my questions:
> 
> 1/ Which are the 'most wanted' packages not yet recompiled/ported to
> Linux/SGI? I've looked at the RPMs available RPM list, and some important
> packages seem unavailable yet. (sed,tar,perl come to mind).

sed, tar: confilicting declaration in source and libc.  Both work other-
wise.  Perl: builds shrink wrapped & works, just the binary packaging
with RPM fails.  I think because groff/man are missing.  I've got another
two dozen packages on disk which I'll upload when I next pass by in
Mountain View ...

> 2/ While using the crossdev gcc, several times I got complains about a
> file 'sgidefs.h' missing (from
> /usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41). 
> Commenting the '#include' file made the compile work, but I not sure it's
> the right fix. 

Not the right thing, but won't hurt.  I shows that your libc is
not installed correctly.

> 3/ Can any1 confirm/correct the following values for GNU/autoconf:

> ac_cv_c_bigendian=no

MIPS CPUs can be configured for both byte orders.  SGI, Mips Inc.,
Sony machines are wired big endian, most other machines are little
endian or configurable by replacing the firmware.  As a consequence
we have to build all packages twice, once for each byte sex.
mips-linux-* tools are big endian by default, mipsel-linux-* tools
little endian.

> ac_cv_c_char_unsigned=no

True by default, unless you give -funsigned-char.

> ac_cv_sizeof_long=4
> ac_cv_sizeof_int=4

True by default in the mips{el}-linux configurations; the size of
these types can be changed by -mlong64 and -mint64.  These options
are incompatible with libc, so I mention them only for completeness.

  Ralf

Re: your mail

[Ralf Baechle]

> 	I've just joined this ML, and I'm trying to contribute to the
> Linux/SGI development. Since I'm not too good at kernel hacking, I've
> tough about working on porting the userland part (I have some experience
> with this part since I've been a Debian developper for a while and
> initiated the Debian/PowerPC port).
> 	By now I don't have access to any SGI hardware, but i've been able
> to build some packages with the crossdev (i486-linux) packages from
> ftp.linux.sgi.com.
> 
> 	So here are my questions:
> 
> 1/ Which are the 'most wanted' packages not yet recompiled/ported to
> Linux/SGI? I've looked at the RPMs available RPM list, and some important
> packages seem unavailable yet. (sed,tar,perl come to mind).

sed, tar: confilicting declaration in source and libc.  Both work other-
wise.  Perl: builds shrink wrapped & works, just the binary packaging
with RPM fails.  I think because groff/man are missing.  I've got another
two dozen packages on disk which I'll upload when I next pass by in
Mountain View ...

> 2/ While using the crossdev gcc, several times I got complains about a
> file 'sgidefs.h' missing (from
> /usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41). 
> Commenting the '#include' file made the compile work, but I not sure it's
> the right fix. 

Not the right thing, but won't hurt.  I shows that your libc is
not installed correctly.

> 3/ Can any1 confirm/correct the following values for GNU/autoconf:

> ac_cv_c_bigendian=no

MIPS CPUs can be configured for both byte orders.  SGI, Mips Inc.,
Sony machines are wired big endian, most other machines are little
endian or configurable by replacing the firmware.  As a consequence
we have to build all packages twice, once for each byte sex.
mips-linux-* tools are big endian by default, mipsel-linux-* tools
little endian.

> ac_cv_c_char_unsigned=no

True by default, unless you give -funsigned-char.

> ac_cv_sizeof_long=4
> ac_cv_sizeof_int=4

True by default in the mips{el}-linux configurations; the size of
these types can be changed by -mlong64 and -mint64.  These options
are incompatible with libc, so I mention them only for completeness.

  Ralf

Re: your mail

[Vincent Renardias]

On Sat, 9 Aug 1997, Ralf Baechle wrote:

> > 2/ While using the crossdev gcc, several times I got complains about a
> > file 'sgidefs.h' missing (from
> > /usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41). 
> > Commenting the '#include' file made the compile work, but I not sure it's
> > the right fix. 
> 
> Not the right thing, but won't hurt.  I shows that your libc is
> not installed correctly.

I just installed the binutils/gcc crossdev packages from
ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
(i386).

[Thanx for the explanation on endianess ;]

	Cordialement,

--
-     ** Linux **         +-------------------+             ** WAW **     -
-  vincent@debian.org     | RENARDIAS Vincent |          vincent@waw.com  -
-  Debian/GNU Linux       +-------------------+      http://www.waw.com/  -
-  http://www.debian.org/           |            WAW  (33) 4 91 81 21 45  -
---------------------------------------------------------------------------

Re: your mail

[Ralf Baechle]

> > Not the right thing, but won't hurt.  I shows that your libc is
> > not installed correctly.
> 
> I just installed the binutils/gcc crossdev packages from
> ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
> from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
> (i386).

Well, it doesn't matter except that I built the executables with Linux
libc and you therefore need that one.  DANGER:  When you install libs
for a crosscompiler you will have to move the libs a bit around.
Just doing tar zxf ... -C / will fry your native system.  MIPS stuff
just has too much octane to be suitable as fuel for your Intel machine ;-)

Btw, as I'm writing this I've built about 88mb of binary .rpm packages
running native.  The sole problems I currently have is that the kernel
seems to have some memory corruption problem.  That is nasty because
it usually hits the bitmaps ...  It might as well explain Miguel's
recently reported NFS problem.

  Ralf

Re: your mail

[Ralf Baechle]

> > Not the right thing, but won't hurt.  I shows that your libc is
> > not installed correctly.
> 
> I just installed the binutils/gcc crossdev packages from
> ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
> from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
> (i386).

Well, it doesn't matter except that I built the executables with Linux
libc and you therefore need that one.  DANGER:  When you install libs
for a crosscompiler you will have to move the libs a bit around.
Just doing tar zxf ... -C / will fry your native system.  MIPS stuff
just has too much octane to be suitable as fuel for your Intel machine ;-)

Btw, as I'm writing this I've built about 88mb of binary .rpm packages
running native.  The sole problems I currently have is that the kernel
seems to have some memory corruption problem.  That is nasty because
it usually hits the bitmaps ...  It might as well explain Miguel's
recently reported NFS problem.

  Ralf

Re: your mail

[Vincent Renardias]

On Sat, 9 Aug 1997, Ralf Baechle wrote:

> > I just installed the binutils/gcc crossdev packages from
> > ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
> > from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
> > (i386).
> 
> Well, it doesn't matter except that I built the executables with Linux
> libc and you therefore need that one.  DANGER:  When you install libs
> for a crosscompiler you will have to move the libs a bit around.
> Just doing tar zxf ... -C / will fry your native system.  MIPS stuff
> just has too much octane to be suitable as fuel for your Intel machine ;-)

Debian provides nice tools to handdle this kind of installation:

- alien: allows to convert binary packages between any 2 of the
{.deb,.tgz,.rpm} formats.

- dpkg-cross: tool handdling cross-compilation packages. That is any file
that should go into /*/lib is redirected into /usr/local/$ARCH-linux/lib.
(same for the include files). It also makes it possible to build a given
package for several architectures at the same time.
Those tools should probably work on any Linux flavour (distrib./arch.)

Anyway, I've installed glibc-2.0.4 to get around the missing sgidefs.h
problem, and I run into another problem:
now mips-linux-gcc complains about:

% mips-linux-gcc  -o pwgen pwgen.o -lm
/usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
index; run ranlib to add one

running mips-linux-ranlib on the given file does not change anything.
(ie: still getting the same message)

Did I do anything wrong, or is this a problem in the Linux/SGI glibc?

	Cordialement,

--
-     ** Linux **         +-------------------+             ** WAW **     -
-  vincent@debian.org     | RENARDIAS Vincent |          vincent@waw.com  -
-  Debian/GNU Linux       +-------------------+      http://www.waw.com/  -
-  http://www.debian.org/           |            WAW  (33) 4 91 81 21 45  -
---------------------------------------------------------------------------

Re: your mail

[Ralf Baechle]

> % mips-linux-gcc  -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
> 
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)
> 
> Did I do anything wrong, or is this a problem in the Linux/SGI glibc?

No.  Looks as if your lib still isn't correctly installed.  If ranlib
doesn't help, then your libc.a is probably corrupted into a zero lenght
file.

  Ralf

Re: your mail

[Ralf Baechle]

> % mips-linux-gcc  -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
> 
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)
> 
> Did I do anything wrong, or is this a problem in the Linux/SGI glibc?

No.  Looks as if your lib still isn't correctly installed.  If ranlib
doesn't help, then your libc.a is probably corrupted into a zero lenght
file.

  Ralf

Re: your mail

[Vincent Renardias]

On Sat, 9 Aug 1997, Ralf Baechle wrote:

> > % mips-linux-gcc  -o pwgen pwgen.o -lm
> > /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> > index; run ranlib to add one
> > 
> > running mips-linux-ranlib on the given file does not change anything.
> > (ie: still getting the same message)
> > 
> > Did I do anything wrong, or is this a problem in the Linux/SGI glibc?
> 
> No.  Looks as if your lib still isn't correctly installed.  If ranlib
> doesn't help, then your libc.a is probably corrupted into a zero lenght
> file.

You're right. (Not an empty file through, but somehow it got truncated to
~50 K). Reinstalling fixed it.

Here's the list of what I compiled so far:

file_3.20.1-6_mips.deb              gzip_1.2.4-15_mips.deb
debmake_3.3.11_mips.deb             grep_2.0-12_mips.deb
dpkg-dev_1.4.0.8_all.deb            makedev_1.6-16_mips.deb
dpkg_1.4.0.8_mips.deb               sysklogd_1.3-17_mips.deb
dpkg_1.4.0.8_mips.nondebbin.tar.gz  update_1.3-1_mips.deb
cpio_2.4.2-11_mips.deb              tar_1.12-1_mips.deb
patch_2.2-1_mips.deb                sed_2.05-15_mips.deb
flex_2.5.4a-1_mips.deb              findutils_4.1-23_mips.deb
bison_1.25-9_mips.deb               shellutils_1.16-4_mips.deb
diff_2.7-13_mips.deb                textutils_1.22-2_mips.deb
rpm_2.4.2-2_mips.deb                pwgen_1-8_mips.deb
adduser_3.6_all.deb

These packages are available from odin.waw.com/pub/linux (the pgp signed
checksums are in the changes/ subdirectory). I'd be glad if someone could
test a few of them and tell me if everything is okay.

Quick install instructions:
untar the file dpkg_1.4.0.8_mips.nondebbin.tar.gz at the root of your FS,
then install other packages with 'dpkg -i foo.deb'.

	Cordialement,

-- 
-     ** Linux **         +-------------------+             ** WAW **     -
-  vincent@debian.org     | RENARDIAS Vincent |          vincent@waw.com  -
-  Debian/GNU Linux       +-------------------+      http://www.waw.com/  -
-  http://www.debian.org/           |            WAW  (33) 4 91 81 21 45  -
---------------------------------------------------------------------------

Re: your mail

[Mike Shaver]

Thus spake Vincent Renardias:
> % mips-linux-gcc  -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
> 
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)

Did you use mips-linux-ar to create the archive?
Many packages, I've discovered, don't listen to $AR in the
environment, and I used to get that error all the time.

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>            Chief System Architect and Herder of Bits                
#>                                                                     
#> "Yoda say, `Just slap a little public key crypto into it' does not  
#>      a secure system make." -- Marcus J. Ranum (mjr@clark.net)      

Re: your mail

[Mike Shaver]

Thus spake Vincent Renardias:
> % mips-linux-gcc  -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
> 
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)

Did you use mips-linux-ar to create the archive?
Many packages, I've discovered, don't listen to $AR in the
environment, and I used to get that error all the time.

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>            Chief System Architect and Herder of Bits                
#>                                                                     
#> "Yoda say, `Just slap a little public key crypto into it' does not  
#>      a secure system make." -- Marcus J. Ranum (mjr@clark.net)      

Re: Linux GGI and Linux/SGI

[Miguel de Icaza]

> I'm not so attached to the notion of GGI as much as for gfx
> having an in-kernel-space presence in Linux (Linux/SGI is
> going to need this, as I suspect is any Linux that attempts
> hardware acceleration of OpenGL or other similar APIs).

What does 'gfx' mean in this context?

Linux/SGI currently supports direct rendering (modulo the fact that I
have not written the code to context switch the card state, which
should be trivial to do).

With direct rendering you do not need any graphics acceleration code
in the kernel, you just need to implement the smart tricks the SGI
graphics people came up with and implement some small kernel support
for making the direct rendering applications and the X server work
together. 

Check the www.linux.sgi.com page for a pointer to Mark's paper on this
matter, but the idea is that we let any application that needs to talk
directly to the hardware to map the video card registers into his
address space.  We already have the code that implements the lazy
context switches for the video card [1] and bits of the resource
manager.

The code we will have on Linux/SGI is far better for the SGI case than
what the GGI people have now and as a side beneffit it will let us run
stock Irix Xsgi server.

[1] the mmu code, not the actual switch, I will do that next, as I
mentioned before, 

Re: Linux GGI and Linux/SGI

[Miguel de Icaza]

> Are there any plans to move (maybe it's already there) the
> SGI version of Linux to a GGI-model design?
> (see http://synergy.foo.net/~ggi/)

It is nice, but they assume that a frame buffer is available on the
system, the GGI acceleration features are not even close to what the
low end Indy machines have, they are too general acceleration
features.  

We will support the direct rendering interface on Linux/SGI, which
will take care of using the nice SGI hardware. 

Miguel.