David Miller is on the list

David Miller is on the list

[Ariel Faigon]

Just so you all know.

David Miller is now on the linux@engr.sgi.com mailing list
on majordomo@engr.

Welcome David!  If you want to see some history,
I believe Larry has been archiving these emails somewhere.

I hope this works fine with external addresses. If not, please
let me know.
-- 
Peace, Ariel

Re: David Miller is on the list

[David S. Miller]

   From: ariel@yon.engr.sgi.com (Ariel Faigon)
   Date: Mon, 22 Apr 1996 18:03:04 -0700 (PDT)

   Welcome David!  If you want to see some history,
   I believe Larry has been archiving these emails somewhere.

Howdy...

   I hope this works fine with external addresses. If not, please
   let me know.

Read ya loud and clear, as you can see ;)

Later,
David S. Miller
davem@caip.rutgers.edu

Re: David Miller is on the list

[David S. Miller]

   From: ariel@yon.engr.sgi.com (Ariel Faigon)
   Date: Mon, 22 Apr 1996 18:16:30 -0700 (PDT)

   Great, now you can tell the list what do you need :-)

Oh boy.

   Seriously, we've been thinking about how we could make you most
   productive and not waste your time when you arrive here.

   Here's a recent posting of mine, so you get the idea just in case
   Simon or Bob or Larry didn't tell you about all this yet...

   Feel free to bombard us with requests/questions.
   There are about 20 people on the linux list at SGI
   (you can query majordomo@engr.sgi.com  for the details)

Already did that an hour ago ;)

(note: I looked back over this mail after composing it and I want to
       warn people who are not familiar with me yet that I am very
       sarcastic and am full of ridicule even when discussing
       important topics.  Please don't take it that I lack tact
       or am not being serious, because that simply isn't the case.)

Here is what I need:

	The following utilities I need for development.
	1) CVS/RCS, latest on prep.ai.mit.edu is fine
	2) Emacs-19.31 (rms should release within 2 weeks)
	3) All GNU smidgen-type utilies as the default binaries
	   (this include fileutils/sh-utils/sharutils/diffutils/
	    findutils/...)
	   Actually, Let me just stop short and say, if there is a
	   source tarball for it on prep.ai.mit.edu:/pub/gnu I would
	   like the latest installed on the machine I develop on.
	4) xfishtank (don't laugh)
	5) fvwm
	6) teco (Must support full teco command set as described
	   in original DEC manuals! TECO is _the_ renaissance editor!)

	The following would be nice, but if it will give people
	bladder problems to do these then don't go out of your
	way:
	1) MIPS 4[40]00 manual is some online format (not postscript,
	   something I can cut and paste out of an emacs buffer etc.
	   so maybe info or pure ascii text would be fine, I could
	   care less about the formatting, I just want the words
	   there)
	2) Docs on the ethernet/scsi interfaces and I/O bus
	   architecture for the first machine I will be getting
	   this to work on, again text/info format would be nice.
	   Of course I will probably just stuff in the ready
	   drivers you might be getting to me into Linux but I want
	   to write my own from scratch in the near future after
	   that.
	3) I know as much as a bum on the street about SGI machines
	   and the various lines, a nice "roadmap to sgi workstations
	   and servers, plus the hardware gook thats inside" type
	   thing would be very useful to me.

	I will feel more comfortable if:
	1) I became very familiar with who the heavy low level MIPS
	   assembly level hackers are who I will be dealing with while
	   I am there.  Please tell me who they are, introduce, make
	   us say hello to each other, you get the idea.

	2) I know the policy on loud music in the office I'll be in
	   ;-)

I've thought it over and to me the best plan for things this summer to
me is:
	a) R4400 32-bit "proof of concept, yeah we can pull it off"
	   port happens first, side effect is that I become intimate
	   enough with the chip that I can do things more efficiently.
	b) From here we look into the 64-bit stuff and whether that is
	   is even desirable on 64-bit.  (this would be my first
	   64-bit port outside of my initial UltraSparc hacks)
	c) Also think about the work needed to turn that code into
	   r3000 friendly code.  Should not be too much as I've done
	   the "write it on recent architecture design then backport
	   it to older design which had some limitations" already and
	   this didn't end up being so bad.

Expect more as I think it up... this should keep you guys busy for
now.

(Any dead-head tape traders at SGI engineering?  Just wondering, may
 want to start talking to them now ;-)

Later,
David S. Miller
davem@caip.rutgers.edu

Re: David Miller is on the list

[Ariel Faigon]

>
>(note: I looked back over this mail after composing it and I want to
>       warn people who are not familiar with me yet that I am very
>       sarcastic and am full of ridicule even when discussing
>       important topics.  Please don't take it that I lack tact
>       or am not being serious, because that simply isn't the case.)
>
Feel free to express yourself, my english (colloquial and otherwsie)
is bad anyway, and I guess the others don't care :-)


>Here is what I need:
>
>	The following utilities I need for development.
>	1) CVS/RCS, latest on prep.ai.mit.edu is fine
>
RCS comes default with IRIX today. But I know it is not
the latest. OK, and I'll add cvs.


>	2) Emacs-19.31 (rms should release within 2 weeks)
>	3) All GNU smidgen-type utilies as the default binaries
>	   (this include fileutils/sh-utils/sharutils/diffutils/
>	    findutils/...)
>	   Actually, Let me just stop short and say, if there is a
>	   source tarball for it on prep.ai.mit.edu:/pub/gnu I would
>	   like the latest installed on the machine I develop on.
>
Many of these are in our freeware project. Ready to install with
the click of a mouse. (Yes, one of the cool things about SGI is
a joe-user software installer infinitely better than RPM/glint.)

(yon) 84 /var/tmp> which find
/usr/freeware/bin/find
(yon) 85  /var/tmp> which tar
/usr/freeware/bin/tar
(yon) 86 /var/tmp> which grep
/usr/freeware/bin/grep
(yon) 87 /var/tmp> which chmod
/usr/freeware/bin/chmod


I'll add the missing ones. That's easy.

BTW, we called it '/usr/freeware' rather than '/usr/gnu' because
many packages are from other sources and because some of our
customers asked us to stay away from their /usr/local.


>	4) xfishtank (don't laugh)
>
Bingo. Larry runs this too. You weird people. Is this a conspiracy? :-)


>	5) fvwm
>
>	6) teco (Must support full teco command set as described
>	   in original DEC manuals! TECO is _the_ renaissance editor!)
>
I'll try to build these too.


>	The following would be nice, but if it will give people
>	bladder problems to do these then don't go out of your
>	way:
>	1) MIPS 4[40]00 manual is some online format (not postscript,
>	   something I can cut and paste out of an emacs buffer etc.
>	   so maybe info or pure ascii text would be fine, I could
>	   care less about the formatting, I just want the words
>	   there)

For MIPS ABI stuff: try the following web site,

	http://www.mipsabi.org/
Especially:
	http://www.mipsabi.org/Tech/Technical.html

Tell us what's missing there.

As for the MIPS programmer's Assembly manual. There is an excellent one
internally on the Web... I'll try to get you a copy soon.




>	2) Docs on the ethernet/scsi interfaces and I/O bus
>	   architecture for the first machine I will be getting
>	   this to work on, again text/info format would be nice.
>	   Of course I will probably just stuff in the ready
>	   drivers you might be getting to me into Linux but I want
>	   to write my own from scratch in the near future after
>	   that.
>	3) I know as much as a bum on the street about SGI machines
>	   and the various lines, a nice "roadmap to sgi workstations
>	   and servers, plus the hardware gook thats inside" type
>	   thing would be very useful to me.
>
I'll leave these to some other folks on the list.



>	I will feel more comfortable if:
>	1) I became very familiar with who the heavy low level MIPS
>	   assembly level hackers are who I will be dealing with while
>	   I am there.  Please tell me who they are, introduce, make
>	   us say hello to each other, you get the idea.
>
I believe the most knowledgable low-level gurus on the list are
Bill Earl and Jim Barton, I'm sure there are more, I just don't
know everyone on the list personally ...



>	2) I know the policy on loud music in the office I'll be in
>	   ;-)
>
I'm trying to get you an office right by mine :-)


>I've thought it over and to me the best plan for things this summer to
>me is:
>	a) R4400 32-bit "proof of concept, yeah we can pull it off"
>	   port happens first, side effect is that I become intimate
>	   enough with the chip that I can do things more efficiently.
>	b) From here we look into the 64-bit stuff and whether that is
>	   is even desirable on 64-bit.  (this would be my first
>	   64-bit port outside of my initial UltraSparc hacks)
>	c) Also think about the work needed to turn that code into
>	   r3000 friendly code.  Should not be too much as I've done
>	   the "write it on recent architecture design then backport
>	   it to older design which had some limitations" already and
>	   this didn't end up being so bad.
>
Cool.

>Expect more as I think it up... this should keep you guys busy for
>now.
>
>(Any dead-head tape traders at SGI engineering?  Just wondering, may
> want to start talking to them now ;-)
>
You'll find lots of them here ;-)

-- 
Peace, Ariel

Re: David Miller is on the list

[David S. Miller]

   From: ariel@yon.engr.sgi.com (Ariel Faigon)
   Date: Mon, 22 Apr 1996 19:16:30 -0700 (PDT)

   >
   >(note: I looked back over this mail after composing it and I want to
   >       warn people who are not familiar with me yet that I am very
   >       sarcastic and am full of ridicule even when discussing
   >       important topics.  Please don't take it that I lack tact
   >       or am not being serious, because that simply isn't the case.)
   >
   Feel free to express yourself, my english (colloquial and otherwsie)
   is bad anyway, and I guess the others don't care :-)

Cool, I feel much more comfortable now ;)

   >	4) xfishtank (don't laugh)
   >
   Bingo. Larry runs this too. You weird people. Is this a conspiracy? :-)

Nope, not a conspiracy.  Grab a copy of:

caip.rutgers.edu:/pub/davem/penguin.gif

Then run 'xfishtank -p penguin.gif' after hacking endlessly on down
and dirty kernel code for 20 hours straight with no sleep and direct
intraveinus coffee keeping you going, and tell me that isn't the damn
most funniest thing you've ever seen in your life. (note said
description is the state I am in right now, whee... oh yeah, and the
penguin picture was found in Linus's home directory on
linux.cs.helsinki.fi one late night I was hacking on there :)

   For MIPS ABI stuff: try the following web site,

	   http://www.mipsabi.org/
   Especially:
	   http://www.mipsabi.org/Tech/Technical.html

   Tell us what's missing there.

   As for the MIPS programmer's Assembly manual. There is an excellent one
   internally on the Web... I'll try to get you a copy soon.

Noted, I'll check some of that out.  Thanks.

   >(Any dead-head tape traders at SGI engineering?  Just wondering, may
   > want to start talking to them now ;-)
   >
   You'll find lots of them here ;-)

Oh, yummy, heaven on earth.

Later,
David S. Miller
davem@caip.rutgers.edu

Re: David Miller is on the list

[Larry McVoy]

:    >	4) xfishtank (don't laugh)
:    >
:    Bingo. Larry runs this too. You weird people. Is this a conspiracy? :-)
: 
: Nope, not a conspiracy.  Grab a copy of:
: 
: caip.rutgers.edu:/pub/davem/penguin.gif
: 
: Then run 'xfishtank -p penguin.gif' after hacking endlessly on down

Nah, try this:

	xearth &
	xfishtank -d

Fish in spaaaaaaaaaaaaaaace!

Re: David Miller is on the list

[David S. Miller]

   From: lm@gate1-neteng.engr.sgi.com (Larry McVoy)
   Date: Mon, 22 Apr 1996 19:35:59 -0700

   Fish in spaaaaaaaaaaaaaaace!

YESSSS!!! way cool larry

Oh man, in my .xinitrc this goes...

Later,
David S. Miller
davem@caip.rutgers.edu

Re: David Miller is on the list

[David S. Miller]

Actually, here's an important issue.  I get to name my machines right?

Later,
David S. Miller
davem@caip.rutgers.edu

Re: David Miller is on the list

[jon madison]

Ariel Faigon quoted, a little while back,
#>	5) fvwm
ariel, if you can't i'll swing it (i run bowman here...(bowman's
a 'better' fvwm (looks like NeXTStep...the GoodStuff is like NeXT's
dock)

j.

-- 
jon madison, silicon graphics, inc. 
us: <URL: http://www.sgi.com/>
mailto:jm@sgi.com        
me: <URL: http://klingon.iupucs.iupui.edu/~jmadison/>

Re: David Miller is on the list

[Bob Mende Pie]

On Apr 22,  7:35pm, Larry McVoy wrote:
> Subject: Re: David Miller is on the list
> :    >	4) xfishtank (don't laugh)
> :    >
> :    Bingo. Larry runs this too. You weird people. Is this a conspiracy? :-)
> :
> : Nope, not a conspiracy.  Grab a copy of:
> :
> : caip.rutgers.edu:/pub/davem/penguin.gif
> :
> : Then run 'xfishtank -p penguin.gif' after hacking endlessly on down
>
> Nah, try this:
>
> 	xearth &
> 	xfishtank -d
>
> Fish in spaaaaaaaaaaaaaaace!

And all of the fish are bubbling the same thing ... "cpu ... more cpu ..."

:-)


-- 
				      /Bob...			 mende@sgi.com
				http://reality.sgi.com/mende/

Re: David Miller is on the list

[Bob Mende Pie]

On Apr 22,  7:35pm, Larry McVoy wrote:
> Subject: Re: David Miller is on the list
> :    >	4) xfishtank (don't laugh)
> :    >
> :    Bingo. Larry runs this too. You weird people. Is this a conspiracy? :-)
> :
> : Nope, not a conspiracy.  Grab a copy of:
> :
> : caip.rutgers.edu:/pub/davem/penguin.gif
> :
> : Then run 'xfishtank -p penguin.gif' after hacking endlessly on down
>
> Nah, try this:
>
> 	xearth &
> 	xfishtank -d
>
> Fish in spaaaaaaaaaaaaaaace!

And all of the fish are bubbling the same thing ... "cpu ... more cpu ..."

:-)


-- 
				      /Bob...			 mende@sgi.com
				http://reality.sgi.com/mende/

Re: David Miller is on the list

[William J. Earl]

David S. Miller writes:
 >    From: ariel@yon.engr.sgi.com (Ariel Faigon)
 >    Date: Mon, 22 Apr 1996 18:16:30 -0700 (PDT)
...
 > 	1) MIPS 4[40]00 manual is some online format (not postscript,
 > 	   something I can cut and paste out of an emacs buffer etc.
 > 	   so maybe info or pure ascii text would be fine, I could
 > 	   care less about the formatting, I just want the words
 > 	   there)

     The manuals are online, generally at www,mips.com.  For example,

	http://www.mips.com/r4400/UMan/R4400_UM_cv.html

is the latest R4400 manual.

     Our newer processors for low-end systems are the R4600 and now the
R5000.  Most Indy systems now ship with R5000 processors, and the Indy should
be the target for the initial port, since it is in current production and
widely available.

     The R4600 and R5000 are generally similar, except that the R4600
has 16 KB primary caches and is MIPS III, whereas the R5000 has 32 KB
primary caches and is MIPS IV.  Both are fairly similar to the R4000PC
and R4400PC, in the sense that they do not have a secondary cache
which enforces primary cache virtual index coherency.  (Many Indy
R4600 and R5000 systems do have secondary caches, but they do not
supply virtual coherency exceptions.)  The R4600 and R5000 are good
targets for an initial port, because they have the fewest errata, and
hence require the fewest kernel workarounds.  The R4000 workarounds,
in particular, are pretty messy.

     The R4600 and R5000 data sheets may be found via

	http://www.idt.com/risc/Welcome.html

(under the 64-bit RISC microprocessors category).  The manuals are not online
on public servers, but I can track down copies.  There is some more 
R4600 and R5000 information under

	http://www.qedinc.com/

There is a comparison of the R4400 and the R4600 at

	http://www.mips.com/r4400/Des_Com/Des_Com_cv.html

The MIPS IV architecture document is

	http://www.mips.com/arch/MIPS4_cv.html

This is of relatively minor importance for a basic port, but can be used
to good effect to improve graphics and application performance.  There are
a few minor kernel support issues.

     Once the basic port is done, extending it to the other common processors,
such as the R3000, R4000, R4400, and R10000, will be fairly simple.  The R6000
(not common and obsolete for some years now) and the R8000 would be somewhat
more work to support, since they differ more from the other processors in 
the kernel interface.  

 > 	2) Docs on the ethernet/scsi interfaces and I/O bus
 > 	   architecture for the first machine I will be getting
 > 	   this to work on, again text/info format would be nice.
 > 	   Of course I will probably just stuff in the ready
 > 	   drivers you might be getting to me into Linux but I want
 > 	   to write my own from scratch in the near future after
 > 	   that.

      I have the documents for the memory controller for Indy, and I think
I can locate most of the others.  They are only on paper, however, but I can
get copies.

 > 	3) I know as much as a bum on the street about SGI machines
 > 	   and the various lines, a nice "roadmap to sgi workstations
 > 	   and servers, plus the hardware gook thats inside" type
 > 	   thing would be very useful to me.

     There are tables of the systems under

	http://ssales.corp.sgi.com/products/html/periodic_table.html

Unfortunately, these are inside the firewall.

 > 	I will feel more comfortable if:
 > 	1) I became very familiar with who the heavy low level MIPS
 > 	   assembly level hackers are who I will be dealing with while
 > 	   I am there.  Please tell me who they are, introduce, make
 > 	   us say hello to each other, you get the idea.

     I am probably the best initial contact for Indy issues, and I can
introduce you to people familiar with the various drivers and so on.

...
 > I've thought it over and to me the best plan for things this summer to
 > me is:
 > 	a) R4400 32-bit "proof of concept, yeah we can pull it off"
 > 	   port happens first, side effect is that I become intimate
 > 	   enough with the chip that I can do things more efficiently.

     As I mentioned above, the R4600 and R5000 processors are a simpler
initial target, and the Indy R4600 is the most common configuration.

 > 	b) From here we look into the 64-bit stuff and whether that is
 > 	   is even desirable on 64-bit.  (this would be my first
 > 	   64-bit port outside of my initial UltraSparc hacks)

     This is mainly interesting on the larger systems.  64-bit kernels
do take more space and time (due to extra cache misses, if nothing else),
and most applications don't need more than 32-bit addresses.  The 32-bit
kernel should, however, support using 64-bit arithmetic (MIPS III and IV)
even in 32-bit programs, since there are substantial performance gains
available for certain applications.  The kernel itself can use 64-bit
arithmetic to good effect as well.  (This is how IRIX works.)

 > 	c) Also think about the work needed to turn that code into
 > 	   r3000 friendly code.  Should not be too much as I've done
 > 	   the "write it on recent architecture design then backport
 > 	   it to older design which had some limitations" already and
 > 	   this didn't end up being so bad.

     The R3000 is not drastically different from the R4600.  The main
differences are somewhat different TLB and cache control routines, and, of
course, the MIPS I instruction set.

Re: David Miller is on the list

[Bob Mende Pie]

On Apr 22,  9:40pm, David S. Miller wrote:

> 	5) fvwm

I've got 2.0.42 compiled and running ... But if dave wants to live in the dark
ages of fvwm 1.x thats fine with me.

> 	6) teco (Must support full teco command set as described
> 	   in original DEC manuals! TECO is _the_ renaissance editor!)

I've got it compiled, but beats the hell out of me if it works :-)  Ill make
you a deal, if I see you edit a file with it I bring you my honest to god DEC
PDP-11 teco manual.


-- 
				      /Bob...			 mende@sgi.com
				http://reality.sgi.com/mende/

Re: David Miller is on the list

[Jim Barton]

The purpose for basing the port on R3000 is *not* to support obsolete
workstations and servers; our time and effort need to be directed to the
future, not the past. If the guys in OZ want to port it, fine.

Basing on an R3000 is important because of it's exploding use as an
embedded processor; it's showing up in your laser printers, phone
switches, robots, airplanes, satellite receivers, and so on. One thing
Larry and I are interested in is seeing if Linux is really suitable
as an embedded OS to support these (and more) applications.

What you typically find is an r3k core surrounded by various application-
specific peripherals, e.g, MPEG decoders, sound chips, DMA controllers,
serial controllers. The OS is usually in ROM, and the device manufacturer
adds special drivers to the mix. Real-time constraints come into play;
in particular, it would be interesting to consider what additions to Linux
make it work well for real-time applications. Posix 1003.4 is pretty
heavy-weight, but perhaps we can have a light-weight implementation.

In the workstation/server world, the R4000 is the processor to aim at.
It is significantly different than the r3k in TLB layout, but little
else in 32-bit mode, so the same code should basically work both places.
I believe different binaries should be built for the r4k and r3k - certain
pieces of MIPS II ISA can accelerate performance, and the compilers take
advantage of that.

Given that the workstation/server world is moving to 64 bit, I believe we
need a 64-bit version of Linux as well. The design of the MIPS III ISA
is actually pretty clean for keeping the same source between 32-bit and
64-bit kernels, as long as you are careful about your types.

The r4k is also interesting because it is at the heart of the Nintendo
Ultra-64 game, and the R4300i processor it uses is starting to show up
in various Japanese computer products. The volumes of this device are
projected in the 10s of millions of units, so it is significant. Linux
in your Ultra-64 box? Hmmmm. Might actually be interesting ...

So, we need to be able to build three versions from the same source.
I think the R10K can be ignored for now, and it *only* runs in 64-bit
kernel mode. 64-bit user mode can also be ignored for now - there are
few applications for 64-bit programs except in the high-end scientific
markets. The R8K is obsolete.

-- jmb

Re: David Miller is on the list

[Mike McDonald]

  A dumb question, what exactly is the purpose of porting Linux to
SGI/Mips boxes? At one time, it was proposed as a way that all of the
people how just got dropped from support to maintain there machine's
usefull life. Now, people are talking about embedding linux in
printers and Nintendo boxes! Or as an alternative to Irix on our
current machines. Personally, I think the port should concentrate on
R3K boxes with/without graphics. (It'd be nice if we could release the
info so that X11R6 could be built on the old boxes.) The port should
be a 32 bit port. (Does gcc even support 64 bit MIPS 27 ISA?) It also
be nice if the R3K port would also work on the R4K machines that are
fading away, ie. Indy's, Indigo2's.


  Mike McDonald
  mikemac@engr.sgi.com

Re: David Miller is on the list

[William J. Earl]

Mike McDonald writes:
 > 
 > 
 >   A dumb question, what exactly is the purpose of porting Linux to
 > SGI/Mips boxes? At one time, it was proposed as a way that all of the
 > people how just got dropped from support to maintain there machine's
 > usefull life. Now, people are talking about embedding linux in
 > printers and Nintendo boxes! Or as an alternative to Irix on our
 > current machines. Personally, I think the port should concentrate on
 > R3K boxes with/without graphics. (It'd be nice if we could release the
 > info so that X11R6 could be built on the old boxes.) The port should
 > be a 32 bit port. (Does gcc even support 64 bit MIPS 27 ISA?) It also
 > be nice if the R3K port would also work on the R4K machines that are
 > fading away, ie. Indy's, Indigo2's.

     Different people have different motivations, and you have heard
some of them.  My main interest is in two parts.  First, on
current-production low-end workstations, I would like to compare linux
performance to IRIX performance.  If linux is much better on most
measures, in ways which matter to end users, then we would need to
consider it as a choice for low-end systems.  If it is better only in
some dimensions, then we can use it as an existence proof that there
are ways to improve IRIX in those dimensions.  It is hard to compare
software running on different hardware, but software running on
identical hardware is directly comparable.

     Second, I believe that UNIX-based systems are gratuitously incompatible,
compared to NT, and that this is an impediment to competing against NT in
low-end servers and workstations.  Since most efforts to standardize 
interfaces and administration for UNIX systems have been very slow and
incomplete, due to conflicting interests of the vendors involved, I would
like to try using linux as a vehicle for creating a de facto standard.
Where appropriate, we should give away some enabling technology, such
as Web-based administration scripts.  We really compete on application
performance.  Trying compete in areas such as administrative commands,
which are peripheral to the user's main interests, is, on balance, almost 
certainly counterproductive.  This will be even more the case as we begin
selling into larger installations (with a large number of units, not the
odd one or two systems we often sell at present).

     linux for older boxes is a fine thing, and not unduly difficult
to do, at least on the workstations, but there are a lot more
R4000-and-better boxes out there now.  As for embedded systems, there
are actually pretty decent real time systems, some with POSIX
compliance, which support MIPS processors.  I doubt that the success
of MIPS processors in embedded systems is much limited by software
availability.

What target (was David ...)

[Ariel Faigon]

Mike asked (not a dumb Q, BTW):
>
>  A dumb question, what exactly is the purpose of porting Linux to
>SGI/Mips boxes?
>
Looks like there are many opinions. I don't care as long as we
manage to do this port. Whatever we port it to (and the wider the
port is) SGI is going to benefit tremendously. You may read
my Linux pages (http://info.engr/~ariel/linux) to understand why
my personal conviction (and others) is so strong.

Some of the nice things about Linux are:

	1) It can work from RAM (virtual disk),
	    So it follows that it is easily ROMable and
	    embeddable (much more so than IRIX)

	    I have developed embedded apps for several years in my past
	    and I can tell you that my life would have been infinitely
	    easier had I been able to develop in a Linux env.
	    Only the thought of having the same env on the host
	    and the target is revolutionary by itself (and possible!)

	2) It has a small footprint so naturally it is a good candidate
	   for embedded market.

	3) It has a common single source code for 32-bit and 64-bit
	   machines (Alpha). So we shouldn't think of this as an "either/or"
	   proposition.

P.S.
gcc doesn't have support for 64 bit MIPS 27 ISA, I guess, but
nobody is stopping us from using our compilers (as well as gcc
at our convenience).
-- 
Peace, Ariel

Re: What target (was David ...)

[Mike McDonald]

>From: ariel@yon (Ariel Faigon)
>Subject: What target (was David ...)
>To: linux@yon
>Date: Tue, 23 Apr 1996 13:26:53 -0700 (PDT)

>P.S.
>gcc doesn't have support for 64 bit MIPS 27 ISA, I guess, but
>nobody is stopping us from using our compilers (as well as gcc
>at our convenience).
>-- 
>Peace, Ariel

  I strongly believe that using our compilers would be a "bad" thing
for the initial port. Requiring someone to buy IDO inorder to compile
a free OS seems like the "wrong" thing to me. Now, if we (SGI) decide
to ship a Linux version, then yes, using our compilers is OK. Let's
just make sure that the port is dependant on our compilers in any way
at this point. (I doubt that's what you were suggesting. I just want
to make it clear before we get started.)

  Mike McDonald
  mikemac@engr.sgi.com

Re: What target (was David ...)

[Ariel Faigon]

>Mike dijo:
>>yo dijo:
>>
>>P.S.
>>gcc doesn't have support for 64 bit MIPS 27 ISA, I guess, but
>>nobody is stopping us from using our compilers (as well as gcc
>>at our convenience).
>
>  I strongly believe that using our compilers would be a "bad" thing
>for the initial port. Requiring someone to buy IDO inorder to compile
>a free OS seems like the "wrong" thing to me. Now, if we (SGI) decide
>to ship a Linux version, then yes, using our compilers is OK. Let's
>just make sure that the port is dependant on our compilers in any way
>at this point. (I doubt that's what you were suggesting. I just want
>to make it clear before we get started.)
>
>
Bob and I are working separately on making our compilers (actually only
the C one, not Ada :-) be bundled with Irix (and possibly licence enabled
for a nominal fee, which can be done automatically without human
intervention -- surprisingly this may increase revenues because
the cost of handling goes to zero and the potential upside due to
lowering barriers is large). I think we have a very good chance of
acheiving this as soon as our upcoming big software release.

Also, I agree, we should make sure that whatever we do is buildable
by gcc. And we should also be paying Cygnus to do a real supported
full port (including ld), but this is harder to achieve (need $$$
from management) at this point.  However, after we have Linux and it
takes off, everything related to free software would be possible :-)
-- 
Peace, Ariel

Re: What target (was David ...)

[Ariel Faigon]

>Mike dijo:
>>yo dijo:
>>
>>P.S.
>>gcc doesn't have support for 64 bit MIPS 27 ISA, I guess, but
>>nobody is stopping us from using our compilers (as well as gcc
>>at our convenience).
>
>  I strongly believe that using our compilers would be a "bad" thing
>for the initial port. Requiring someone to buy IDO inorder to compile
>a free OS seems like the "wrong" thing to me. Now, if we (SGI) decide
>to ship a Linux version, then yes, using our compilers is OK. Let's
>just make sure that the port is dependant on our compilers in any way
>at this point. (I doubt that's what you were suggesting. I just want
>to make it clear before we get started.)
>
>
Bob and I are working separately on making our compilers (actually only
the C one, not Ada :-) be bundled with Irix (and possibly licence enabled
for a nominal fee, which can be done automatically without human
intervention -- surprisingly this may increase revenues because
the cost of handling goes to zero and the potential upside due to
lowering barriers is large). I think we have a very good chance of
acheiving this as soon as our upcoming big software release.

Also, I agree, we should make sure that whatever we do is buildable
by gcc. And we should also be paying Cygnus to do a real supported
full port (including ld), but this is harder to achieve (need $$$
from management) at this point.  However, after we have Linux and it
takes off, everything related to free software would be possible :-)
-- 
Peace, Ariel

Re: What target (was David ...)

[Greg Chesson]

I'm pleased that we are getting a Linux port started and that there
is an incredible degree of interest and enthusiasm. This is independent
of which hardware configurations will or should be supported.
I see good reasons for doing all of them.

I hope that the
self-selected "steering committee" will generate some consensus tomorrow
as to priorities.  If there is no consensus, then Larry McVoy and I will
make an "executive decision" based on available hardware resources
and a shortest-path approach to getting a first port.


greg

Re: What target (was David ...)

[Greg Chesson]

Right.

The objective with bringing David in has been to get something started....
a first port as an "enabling technology".  I believe that many good things
will happen as a result.

greg

Re: What target (was David ...)

[Greg Chesson]

Right.

The objective with bringing David in has been to get something started....
a first port as an "enabling technology".  I believe that many good things
will happen as a result.

greg

Re: David Miller is on the list

[David S. Miller]

   Date: Tue, 23 Apr 1996 09:35:24 -0700
   From: wje@fir.esd.sgi.com (William J. Earl)

	There are tables of the systems under

	   http://ssales.corp.sgi.com/products/html/periodic_table.html

   Unfortunately, these are inside the firewall.

This having been noted, is my account at sgi going to be setup soon so
that perhaps I could telnet in using the firewall and look at the docs
mentioned from an internal machine?

Later,
David S. Miller
davem@caip.rutgers.edu

Re: David Miller is on the list

[David S. Miller]

   From: "Bob Mende Pie" <mende@piecomputer.corp.sgi.com>
   Date: Tue, 23 Apr 1996 09:56:42 -0700

   On Apr 22,  9:40pm, David S. Miller wrote:

   > 	5) fvwm

   I've got 2.0.42 compiled and running ... But if dave wants to live in the dark
   ages of fvwm 1.x thats fine with me.

Someone else is building 1.24l for me right now methinks... better
check this out before bucking heads ;)

   > 	6) teco (Must support full teco command set as described
   > 	   in original DEC manuals! TECO is _the_ renaissance editor!)

   I've got it compiled, but beats the hell out of me if it works :-)  Ill make
   you a deal, if I see you edit a file with it I bring you my honest to god DEC
   PDP-11 teco manual.

     [1 J^P$L$$
     J <.-Z; .,(S,$ -D .)FX1 @F^B $K :L I $ G1 L>$$

Later,
David S. Miller
davem@caip.rutgers.edu