Subject: The Plan For Userland(tm)

From: Mike Shaver <[email-masked]>
Date: Mon, 2 Jun 1997 14:21:47 -0400 (EDT)

Here's my plan for getting the userland stuff to critical mass:
- kernel and glibc sync'd.  Shouldn't be too hard, once I get the new
kernel from Ralf.  (At the very least, I need the SOCK_{STREAM,DGRAM}
stuff sorted out, and I'd like to figure out a good strategy for
asm/atomic.h.)
- rpm built
- native gcc built as an rpm
- start building rpms natively, and installing them on a fresh
partition

I think the SCSI driver is dodgy (this may be a known problem), and I
need to get glibc installed on neon to ease the configuration issue,
but I think we're well on our way.

I'm _definitely_ going to need more disk space on neon, but I can
steal the ext2 one from bogomips in the short-term.

Oh, BTW:
[shaver@neon shaver]$ telnet bogomips
Trying 205.207.220.72...
Connected to bogomips.ingenia.com.
Escape character is '^]'.

Linux 2.0.12 (bogomips) (ttyp0)

bogomips login: root
Last login: Mon Jun  2 15:29:21 from neon
# ls
205.207.220.72       libexec              tmp
bin                  linux-2.0.12.tar.gz  usr
dev                  linux-2.1.36.tar.gz  var
etc                  proc                 vmlinux
home                 sbin
lib                  static-bin
# exit
Connection closed by foreign host.
[shaver@neon shaver]$ 

Mike

-- 
#> Mike Shaver ([email-masked]) Ingenia Communications Corporation 
#>                 Ignore the man behind the curtain.                  
#>                                                                     
#> "And then I realized that it never should have worked in the first  
#>  place.  Thus, it would not work again until rewritten." --- Anon.

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 3 Jun 1997 20:23:42 +0200 (MET DST)

> kernel from Ralf.

Sorry, it's taking a bit longer.  In the meantime I synced with .42;
still need to fix some more bugs.

>                   (At the very least, I need the SOCK_{STREAM,DGRAM}

Whith what package again did you have the problems with atomic.h?

> steal the ext2 one from bogomips in the short-term.

Yeah, and if there won't be xfs for linux I'd really like to see ext2
support for IRIX ...

> [shaver@neon shaver]$ telnet bogomips

ssh works also pretty good.  The only problem it has is that my X
pseudo port has still a "couple" of bugs.

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 3 Jun 1997 20:34:33 +0200 (MET DST)

Mike,

btw, if you feel like it you could try if you can build Perl.  I also
don't yet have Pearl but many important packages depend of it.

  Ralf

---

From: Mike Shaver <[email-masked]>
Date: Tue, 3 Jun 1997 14:48:16 -0400 (EDT)

> don't yet have Pearl but many important packages depend of it.

I'll trade you for bash and procps.

Mike

-- 
#> Mike Shaver ([email-masked]) Ingenia Communications Corporation 
#>       Chief System Architect -- Head geek -- System exorcist        
#>                                                                     
#>   "Have you considered a life?  I hear they're quite affordable     
#>          these days." --- [email-masked]

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 3 Jun 1997 21:00:49 +0200 (MET DST)

Hi,

> I'll trade you for bash and procps.

With some patches procps builds like a snap.  Including the X toys :-)
Let me dig them out again.  What's the problem with bash?  I've build
Bash 1.x. (needs source changes) and 2.0 with no problems.

  Ralf

---

From: Alex deVries <[email-masked]>
Date: Tue, 3 Jun 1997 18:13:42 -0400 (EDT)

-----BEGIN PGP SIGNED MESSAGE-----

> > - rpm built

I'm almost there.  _almost_.

I need to link it with libz, which I just realized is really called zlib,
not the zlibc found on prep.ai.mit.edu.  Who knew?  I'm just getting
problmes now with glibc's crt1.o, which I know little or nothing about.

Ralph, can you give us (Mike or I) a copy of your SSH's?  We will in turn
keep you up to date with our userland binaries, and hopefully we can move
towards sharing RPMs, both source and binary. 

mips-linux-gcc, incidentally, is very impressive.

- - Alex

      Alex deVries           "Alex can cut a mean rug."
  System Administrator       - M. Dittberner <[email-masked]>
   The EngSoc Project

---

From: Alex deVries <[email-masked]>
Date: Tue, 3 Jun 1997 18:24:15 -0400 (EDT)

> Ralph, can you give us (Mike or I) a copy of your SSH's?  We will in turn
    ^^^^

Ish.  I'm very, very sorry.  I meant 'Ralf'.

- Alex

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 4 Jun 1997 02:41:14 +0200 (MET DST)

> Ralph, can you give us (Mike or I) a copy of your SSH's?  We will in turn

s/Ralph/Ralf/

> towards sharing RPMs, both source and binary. 

ssh is no big deal.  Builds out of the box.  You will just have to
tell it for which architecture you're building, ie:
./configure --prefix=/usr mips-linux

There is also a rpm source package for libz available, but for now you
can just use the libz.a and includes included with ssh.

> mips-linux-gcc, incidentally, is very impressive.

Just another GCC.

  Ralf

---

From: "Liam Irish" <[email-masked]>
Date: Wed, 4 Jun 1997 10:04:56 -0400

On Jun 3,  8:23pm, Ralf Baechle wrote:
> Subject: Re: The Plan For Userland(tm)
>

>   Ralf
>-- End of excerpt from Ralf Baechle

I'd like to do that.  I've already been talking to some engineers about it.  I
was trying to determine if it already been done.  Guess not.  I think it'd be
easier to put ext2 on irix than xfs on linux, esp considering the other options
involved with xfs.  Would it be 32-bit xfs?

Anyway.  They both interface a VFS, so it should be _too_ bad.  Unfortunately,
I haven't seen to much documentation for VFS on irix.  Well, see if the Mtn
View engineers will help out in that regard.

-- 
Liam Irish
System Engineer					Tampa, FL
Silicon Graphics, Inc.				(813)281-4620
						[email-masked]

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 4 Jun 1997 16:40:19 +0200 (MET DST)

> View engineers will help out in that regard.

The other fun thing is that right now David and some other people are
rewriting the Linux VFS which also has impact on the ext2 code.

  Ralf

---

From: Alex deVries <[email-masked]>
Date: Wed, 4 Jun 1997 13:28:09 -0400 (EDT)

> still need to fix some more bugs.

We're looking forward to it.

> Whith what package again did you have the problems with atomic.h?

procps complains loudly, and doesn't compile although there are other
issues with procps.

> > - rpm built

zlib, rpm 2.4.1 and gzip appear to work.

- Alex

---

From: [email-masked] (Larry McVoy)
Date: Fri, 13 Jun 1997 14:02:24 -0700

Can someone give me some info on what has been done or needs to be done to
have a 100% self hosting Linux development suite on MIPS?  Last I checked,
it was missing the loader & rld.  Is that still true?  If so, do we know
why it is hard?  I have someone that may be willing to fix this if it is
still a problem.  Thanks.

--lm

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 13 Jun 1997 23:52:05 +0200 (MET DST)

> why it is hard?  I have someone that may be willing to fix this if it is

The development suite is fully useable for bootstrapping itself.  Check
the little endian rpm packages on my workstation kernel.panic.julia.de;
they all were built from unchanged RedHat 4.1 source packages and use
shared libraries.

Aside of a possibility to load the kernel from an ext2fs filesystem the
most urgent thing we need currently is debugging, debugging ...

Things look different if we're talking about 64bit.  Last time I checked
with the Kazumoto Koshima who did a 64bit Hurd port to Sony NeWS the
64bit linker was still not what I'd call reliable ...

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 14 Jun 1997 01:29:47 +0200 (MET DST)

> To begin with, excuse my noviceness in this all. Those are LSB binaries,
> whereas the sgi-linux box that I have access to (bogomips.ingenia.com)
> will only run MSB. 
> 
> As written on this list earlier, we don't have bi-endian support.  So,
> which one is it we're going to support to begin with? How is it that Ralf
> is able to execute LSB binaries?
>
> Am I missing something big?

{\grin[evil] Because I've got four types of MIPS boxes running Linux at
home and to two more I've got access.}

I think this also explains why I'm so interested in running biendianess -
I'm running out of diskspace ...

> Also, there was talk of getting merged up with kernel 2.1.4[234].  Any
> luck so far?

Yes.  I haven't merged all the files of my home CVS archive yet into
David's CVS archive from which he sends patches to Linus but the biggest
part is now in sync.

  Ralf

---

From: Alex deVries <[email-masked]>
Date: Fri, 13 Jun 1997 19:30:37 -0400 (EDT)

- Alex "ready to debug, debug, debug!" deVries

---

From: Alex deVries <[email-masked]>
Date: Fri, 13 Jun 1997 19:51:37 -0400 (EDT)

On Sat, 14 Jun 1997, Ralf Baechle wrote:
> Alex wrote:

To address the needs of us lowly folk who have fewer than 2 MIPS boxes[1],
which endian are we going to be supporting first?  It would be _very_
pleasant to be able to run all these binaries that Ralf has prepared. 

Also, exactly how difficult is it to alternate the kernel between big and
little endian? 

This is getting cooler by the minute...

[1] In my case, 0, but access network access to 1.

- Alex

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 14 Jun 1997 02:04:03 +0200 (MET DST)

> pleasant to be able to run all these binaries that Ralf has prepared. 

The dependencies from the byteorder are very low.  As long as we do
not have a kernel with the capability to execute binaries of both byteorder
at the same time byteorder is almost a non-issue for development.  Just
recompiling, that's it.

> Also, exactly how difficult is it to alternate the kernel between big and

Well, depends on what you mean.  The simple solution is just recompiling
everything.  Works for kernel and user apps.  The more complex solution
is to make the kernel capable of running user apps of both byteorder at
the same time.  Among other things this requires that we go through all
the kernel source and fix the user space access routines.  A bit more of
an effort ;-)  Mips already did that once for RISC/os.

> [1] In my case, 0, but access network access to 1.

Slower than 10mbit/s doesn't count :-)

  Ralf

---

From: Miguel de Icaza <[email-masked]>
Date: Fri, 13 Jun 1997 22:12:09 -0500

> pleasant to be able to run all these binaries that Ralf has prepared. 

Some time ago, someone mentioned that making the kernel support both
big endian and little endian binaries in RISC/os consumed too much of
their time. 

The time we will spend trying to get this bloating hack into the
kernel could be easily spent on some more productive things.  

I will put together a root file system and a bunch of rpms soonish
(ie, that is, as soon as I boot my Indy into Linux).

Miguel.

---

From: Alex deVries <[email-masked]>
Date: Sun, 15 Jun 1997 18:54:36 -0400 (EDT)

I'm going to repeat this question because I still haven't gotten a firm
answer.

As previously discussed, there are good reasons to produce a kernel which
can handle bi-endianness.  But, as Mike says, just not this week...

As we speak, Ralf has produced a batch of MIPS LSB binaries that would be
glorious to be able to run.  The kernel that Mike Shaver and I have is
MSB, as are our kernel, cross-compiler and rudamentary binaries.  I
believe this is because we're branching off of Dave M's work.

But, can we please agree on one endianness?  I don't care which it is, so
long as we all agree. Mike and I are quite willing to give up MSB.

My proposal is to use Ralf's LSB binaries as a launchpad[1], and produce
only LSB binaries until we get bi-endianness going. 

Also, Ralf, could you put up a binary of your kernel and a tar ball of
your root fs?

- Alex

[1] Which are mirrored on ftp://ftp.engsoc.carleton.ca/pub/mips if you're
having problems getting them from .de.  That is, until whatever.sgi.com is
setup.

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 16 Jun 1997 02:17:02 +0200 (MET DST)

> only LSB binaries until we get bi-endianness going. 

Well, the point in a bi-endian kernel is that it will give us the possibility
of running binaries with the opposite byteorder of the kernel.  We don't
have that feature available right now, so we're bound to whatever byteorder
the kernel is running.  Which again is fixed on many machines.  This
means that for now we'll have to build both little endian and big endian
binaries; on SGI we'll only be able to execute big endian binaries.

I think your missunderstood that bi-endianess gives us the possibility to
execute binaries of both endianess concurrently on the same kernel.  It
does that but it also give us at all the possibility to run binaries of
the other byteorder.  So your proposal is currently technically not possible.

Btw, question to the SGI gurus - is the kernel byteorder of SGI machines
be reconfigurable?

> Also, Ralf, could you put up a binary of your kernel and a tar ball of

Ok, I'll put it on http://www.uni-koblenz.de/~linux/vmlinux-2.1.42-pre3.gz.
Not on kernel.panic because I've run out of disk space.  Feel free to
put it on your ftp server.  My root fs is definately to big for upload over
a 14.4k line, so stay tuned.

> having problems getting them from .de.  That is, until whatever.sgi.com is

Hmm...  Ariel, Larry or whoever knows about that - what is the current
state of linux.sgi.com?

  Ralf

---

From: "Alistair Lambie" <[email-masked]>
Date: Mon, 16 Jun 1997 15:30:34 +0000

> Btw, question to the SGI gurus - is the kernel byteorder of SGI machines

As the guys in the US won't be in for a while yet.....

My belief is that Indy's were designed to require a PROM change.  I have also
heard that there was a problem running NT that required some mods to the
boards.
These were never released to the field.

So the answer is yes, but in practice no!

Cheers, Alistair

-- 
Alistair Lambie					    [email-masked]
Silicon Graphics New Zealand				  SGI Voicemail: 56791
Level 5, Walsh Wrightson Tower,				    Ph: +64-4-802 1455
94-96 Dixon St, Wellington, NZ			  	   Fax: +64-4-802 1459

---

From: "William J. Earl" <[email-masked]>
Date: Mon, 16 Jun 1997 10:33:59 -0700

> kernel could be easily spent on some more productive things.  

     I reported on the RISC/os experience.  It wasn't so much that it
took too much time, but rather that it was hard to support on the SVR3
kernel interface, due to the messy definition of the streams interface
at the system call level.  It is much easier if you can assume only
dynamically linked binaries, as in SVR4, and you can do much (although
not all) of the work in user mode, and much of the rest of the work
can happen as a side-effect of copyin/copyout.

 > (ie, that is, as soon as I boot my Indy into Linux).

     That is clearly more expedient than trying to do bi-endian binary
support.  Once the source-level endian issues are resolved (and most
should already be resolved in any GNU sources), having both litte-
and big-endian binaries and file systems is fairly simple.

---

From: "William J. Earl" <[email-masked]>
Date: Mon, 16 Jun 1997 10:54:16 -0700

> long as we all agree. Mike and I are quite willing to give up MSB.

     You probably can't agree on one, unless you can agree on one set
of systems.  Most MIPS architecture systems, including all SGI
systems, are big-endian, but all DEC systems and all MIPS Magnum 4000
systems configured to run NT are little-endian.  (All other MIPS
systems are big-endian.)

---

From: "William J. Earl" <[email-masked]>
Date: Mon, 16 Jun 1997 10:56:58 -0700

> So the answer is yes, but in practice no!
...
     Indy never ran anything little-endian, although the memory controller
could in principle support it.  The rest of the system probably would not
work correctly.  As far as I know, only the MIPS Magnum systems really
work both ways.  (They actually work better little-endian, but most were shipped
big-endian.)

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 16 Jun 1997 23:18:40 +0200 (MET DST)

> systems configured to run NT are little-endian.  (All other MIPS

It's worse than that.  SNI RM series is configurable, Algorithmics eval
boards are configurable.  Acer PICA (derived from the Magnum) is le
only, Sony machines are fixed to be, Deskstation MIPS machines are fixed
to le ...

  Ralf

---

From: Mike McDonald <[email-masked]>
Date: Mon, 16 Jun 1997 17:32:56 -0700

>From: Ralf Baechle <[email-masked]>
>Subject: Re: A pointed question about endianness...
>To: wje@fir (William J. Earl)
>Date: Mon, 16 Jun 1997 23:18:40 +0200 (MET DST)
>
>boards are configurable.  

  Is anyone working on the Algorithmics boards? We have 5 of them over
here currently being used with VxWorks (which isn't officially
supported on these boards). I could cause lots of trouble over here if
Linux did work on them. :-)

  Mike McDonald
  [email-masked]

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 17 Jun 1997 02:57:04 +0200 (MET DST)

> Linux did work on them. :-)

Me, I've got a P4032 donated by Algorithmics here.  The port hasn't yet
reached a state where I'd be pround of it, but bascially it works
diskless.  Some guys from a Silicon Valley company are currently also
porting Linux to that port, supported but otherwise mostly independant
from me.  They're using similar board from Algorithmics which is based
on a R5000 derivate.

Ok, patch 2.1.43 just has been released.  **Input** ...

  Ralf

---

From: Mike McDonald <[email-masked]>
Date: Mon, 16 Jun 1997 18:12:43 -0700

>To: mikemac (Mike McDonald)
>Date: Tue, 17 Jun 1997 02:57:04 +0200 (MET DST)
>
>diskless.  

  That's the beast. So, when are you going to stop messing around with
those Indies and start doing some real work? :-)

  Mike McDonald
  [email-masked]