From: email@example.com (Ariel Faigon)
Date: Thu, 13 Mar 1997 16:18:06 -0800 (PST)
3) The target Linux/Indy filesystems were NFS mounted.
Basically we need to mkfs.ext2(8) on the local Indy (as IRIX
supports XFS and EFS both of which are proprietary, Sigh)
It would be best to have a seprate disk (rather than a
partition which may disappear in case of human error)
Get SILO to work, get the latest gcc to work native
and we can start working on userland.
In all actuality I did have real Linux ext2 filesystems on my test
box, only the kernel was network obtained. In fact the stock ext2
filesystem utilities can be compiled on non-Linux platforms out of the
box, they use GNU autoconf. In fact this is what I did to get going
I still had to use IRIX fdisk to label the disk, but then from IRIX I
just ran the mke2fs program to make the ext2 filesystem. Then I'd
boot Linux quickly using nfsroot, mount the ext2 filesystem I had just
created, and I constructed a partition by copying files over from the
nfs partition in this way. It was a pain, but it worked and I was
more interested in seeing results than doing it right at the time. ;-)
Also the rapid pace at which I was making changes to libc which caused
all of the binaries on the partition to be unusable (because of a
change of symbols in the dynamic linker etc.) actually warranted this
A boot loader is really needed though. There are essentially two or
three approaches most ports take to this task:
1) If the machine provides a "BIOS" or ROM interface that the loader
can use to access the raw disk to do I/O operations, the boot
loader only needs to be very minimal. It uses the ext2 filesystem
library, teaches the library at init time to use functions which it
provides to do I/O. It will do so via the ROM interfaces. Also,
some knowledge of the disk labeling scheme is necessary as well.
This is the scheme used by the Sparc port's boot loader, it is the
easiest way to approach this problem and it does not lack any
2) The Alpha port sticks essentially a miniature kernel into the boot
loader. Although I dislike this scheme, I have been told that they
do need to do things this way. Pretty much the boot loader has
full device drivers in it.
I'd suggest scheme 1, I am nearly positive the SGI proms provide all
the facilities necessary to do what I have described. And if I
remember correctly the boot loader that Ralf is using on his SRM
machines does in fact do all of this. It would be beneficial to go
and look at the available boot loaders already coded, I have a
sneaking suspician that someone willing to stare at all of the code in
those boot loaders can get the thing working on an INDY in say 5 or 6
days time with no prior knowledge.
Asking David some questions might be a good idea too.
I'm not sure he is currently on the list, I'll ask
him if he's interested to join.
If I am not on there now, please add me. I'll listen in.
Larry and I are working on setting up linux.sgi.com outside the
SGI firewall. My intention is to set up tcpwrappers so that only
the developers (Ralf, Miguel, Mike) and SGI people could login
and give you complete control of the machine. At which point
you can install ssh or whatever and start sharing sources.
The "official" initial post-David merged source tree should
come from Ralf.
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
David S. Miller, firstname.lastname@example.org /_____________/ / // /_/ ><