[comp.sys.3b1] FYI: "FSF work on a GNU OS" posted to comp.arch

Mariusz@fbits.ttank.com (Mariusz Stanczak) (05/06/91)

So, the decision has been (yippie!) made as to the bases of
the GNU OS, and since some people expressed their interest in 
hacking a new OS for the 3B1 on this forum, I thought it'd be
appropriate to post the article here.

-Mariusz

[the article follows the "reference" line]
mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes:
   
   The Free Software Foundation is beginning work on a GNU operating
   system built on top of the Mach 3.0 microkernel.  There are three
   goals to this project worth noting:
   
   o Binary compatability with 4.4 BSD, and other U*x or U*xish systems
     on other hardware where appropriate, convenient, and consistent with
     the design;
   
   o Posix compliance (in combination with the GNU C Library and the GNU
     C Compiler); and
   
   o Ease of use as well as several new features and functionality.
   
   
   I am interested in constructive criticism on the interfaces, design,
   and implementation from experts in the field of OS research and design
   consistent with the above goals.  Advice from seasoned U*x hackers is
   especially welcome.
   
   We have a mailing list for discussion.  Currently there is little
   discussion on the group; the major contributors to the ideas behind
   the design all live in the Boston area at this point, and work has
   been done via face-to-face communication.  I would like to open the
   field of discussion to a broader base, both to get wider dissemination
   of the ideas behind the current design, as well as to get a greater
   breadth of criticism.  Periodic postings are currently made to the
   mailing list containing a snapshot of the interfaces used by the
   various pieces of the system.  I would like to see discussion as well;
   perhaps we need a critical mass to get this.
   
   Interested individuals should send me email.  I don't regularly read
   the newsgroups to which this message is posted.
   
   
   [U*x is an abbreviation for a well-known trademark of AT&T.  :-)]
   
   	-mib
-- 
INET: Mariusz@fbits.ttank.com
CIS : 71601.2430@compuserve.com
UUCP: ..!uunet!zardoz!ttank!fbits!Mariusz

yarvin-norman@cs.yale.edu (Norman Yarvin) (05/08/91)

Mariusz@fbits.ttank.com (Mariusz Stanczak) quotes:
>|   The Free Software Foundation is beginning work on a GNU operating
>|   system built on top of the Mach 3.0 microkernel.  There are three
>|   goals to this project worth noting:
>|
>|   o Binary compatability with 4.4 BSD

The problem with this that the Mach 'microkernel' is about as big as the
entire 3b1 OS, and then some monster compatible with 4.4BSD is to run as a
process on _top_ of that.  There is no way it will fit in a 3b1.

The other factor to note is that this is _very_ heavy vaporware.  Even the
details of 4.4BSD are not yet out, mostly because it is still in the process
of being written.

--
Norman Yarvin					yarvin-norman@cs.yale.edu
 "Do not think what you want to think until you know what you ought to know."
  (Crow's Law)

Mariusz@fbits.ttank.com (Mariusz Stanczak) (05/09/91)

In article <1991May8.035642.28195@cs.yale.edu>, yarvin-norman@cs.yale.edu (Norman Yarvin) writes:
> The problem with this that the Mach 'microkernel' is about as big as the
> entire 3b1 OS, and then some monster compatible with 4.4BSD is to run as a
> process on _top_ of that.  There is no way it will fit in a 3b1.

Well Norman, you must be more in the known, and I have not seen the code,
but all that I have read about the effort (Mach microkernel, not GNU kernel),
its design goals, and the intent/idea behind it (on a theoretical level)
left me with a completely different picture.  One of the pieces I read (about
the differences between Mach kernel, and the future microkernel [I think in
CTR]) mentioned a 1000 line C code for the whole thing.  True, the microker-
nell needs many layers glued onto it (the BSD "look&feel" in this case) to
become an OS, but it, in itself, should be a few K's big for all I understand.
What do you know that leads you to believe in what you stated above?  It's 
quite a revolation(sp) to me.


> The other factor to note is that this is _very_ heavy vaporware.  Even the
> details of 4.4BSD are not yet out, mostly because it is still in the process
> of being written.

Very true, but then isn't anything that's just being started "vaporware"?
The microkernel idea is just few years old(new), and OSF's implementation
(with all its resources, and commitment) is a couple years away, so GNU's
effort will be a thing coming into fruition for some years ahead.  I'd
begg to differ... vaporware are things that are announced with a particular
date (and usually shady intent), and then not delivered.  In GNU's case,
vaporware might be things that are not worked on, but then its US and nobody
else.  It's a very ambitious effort, and the projection is about right... 
as 4.4BSD develops, so accordingly will the pieces be picked up... after all
you develop for tomorow, not today.  "Everybody" was pledging(sp) OSI commit-
ment before first layer was a reality.  Is there anything "wrong" with that?
I mean look at the results.

-Mariusz
-- 
INET: Mariusz@fbits.ttank.com
CIS : 71601.2430@compuserve.com
UUCP: ..!uunet!zardoz!ttank!fbits!Mariusz

cgy@cs.brown.edu (Curtis Yarvin) (05/11/91)

In article <110@fbits.ttank.com> Mariusz@fbits.ttank.com (Mariusz Stanczak) writes:
>In article <1991May8.035642.28195@cs.yale.edu>, yarvin-norman@cs.yale.edu (Norman Yarvin) writes:
>> The problem with this that the Mach 'microkernel' is about as big as the
>> entire 3b1 OS, and then some monster compatible with 4.4BSD is to run as a
>> process on _top_ of that.  There is no way it will fit in a 3b1.
>
>Well Norman, you must be more in the known, and I have not seen the code,
>but all that I have read about the effort (Mach microkernel, not GNU kernel),
>its design goals, and the intent/idea behind it (on a theoretical level)
>left me with a completely different picture.  One of the pieces I read (about
>the differences between Mach kernel, and the future microkernel [I think in
>CTR]) mentioned a 1000 line C code for the whole thing.

Your decimals need some work.

We have Mach 3.0 code here.  Note that this is NOT the version with BSD
wedged into the kernel.

Kernel source alone is about 100,000 lines of code.  This does not include
any of the machine-specific sections, which can be quite large; for example,
the i386 machine-specific code is 40,000 lines.

>True, the microkernel needs many layers glued onto it (the BSD "look&feel"
>in this case) to become an OS, but it, in itself, should be a few K's big
>for all I understand.  What do you know that leads you to believe in what
>you stated above?  It's quite a revolation(sp) to me.

I can't quote a source on this, but I believe I remember a discussion -
maybe in comp.arch - initiated by a shocked reader who booted Mach on his
386 and found it was 300k.

>> The other factor to note is that this is _very_ heavy vaporware.  Even the
>> details of 4.4BSD are not yet out, mostly because it is still in the process
>> of being written.
>
>Very true, but then isn't anything that's just being started "vaporware"?
>The microkernel idea is just few years old(new), 

The idea is about ten years old.

>and OSF's implementation (with all its resources, and commitment) is a
>couple years away.

A prerelease version of OSF/1 is running quite stably on a Decstation 3100
here at Brown.  Note that OSF/1 is BSD wedged into the microkernel, not
built around it.

>I'd begg to differ... vaporware are things that are announced with a
>particular date (and usually shady intent), and then not delivered.

Vaporware is any software or hardware which has been announced but not yet
completed.

Curtis

alex@umbc4.umbc.edu (Alex S. Crain) (05/11/91)

I'm pretty sure that curtis said these things...

>We have Mach 3.0 code here.  Note that this is NOT the version with BSD
>wedged into the kernel.
>
>Kernel source alone is about 100,000 lines of code.  This does not include
>any of the machine-specific sections, which can be quite large; for example,
>the i386 machine-specific code is 40,000 lines.

	[...]

>I can't quote a source on this, but I believe I remember a discussion -
>maybe in comp.arch - initiated by a shocked reader who booted Mach on his
>386 and found it was 300k.

	[...]

somebody else said..
>>> The other factor to note is that this is _very_ heavy vaporware.

	Ho hum, ho hum. I've been fooling around with this (conceptually 
anyway) and I have some thoughts.

	[1] Mach is certainly not vaporware, I have the sources in front
of me now. They don't include a 68k port, but they are free and availble
for 386 and mips architectures.

	[2] I think that mach plus the unix layer would be pointless on
the unixpc, (a) because its big and (b) because of the time involved to
make it as stable as the unixpc kernel. Mostly (b).

	I think that people don't appreciate the unixpc kernel for what it
is. My machine is up for weeks/monthes at a time, the documentation is
pretty good, and for the most part, it works as advertised. The few bugs
there are are well known at this point, and somebody on this group can
tell you almost anything that you want to know about the box. Say that
about zenix, Microport or any of a dozen competing systems (tried to
support an Ardent titan lately?) The software is getting dated, but
there's a good C compiler, debugger and editor availabe, and modern graphics
is too heavy for our hardware anyway.

	[3] None the less, I think that mach is intreaging, because it
provides a way to run something other then unix on this machine. I'm 
thinking standalone programs here, something thats developed under unix
and runs in place of the unix kernel.

	There already is one solution available, the diagnostics disk. I've
been running standalone programs the link to the diagnostics code for
awhile, but its very grody and undocumented. 

	Mach is pretty big, but its also segmented well, so it can be run
without some of the modules (like the networking drivers, and the debugger,
and a few other things). A flat file system that would run in a disk partition
would be easy to code, and most of the drivers could be based on what
comes with the diagnostics disk code.

	So anyway, I might try and bring it up this summer if I can
find time. It shouldn't take too long, and I'd be happy to share the 
effort if someone was interested. Of course, I may never get time, in
which case someone else should do it :-). But I think that its a really
good idea.




	


-- 
#################################		           :alex.
#Disclaimer: Anyone who agrees  #                 Systems Programmer
#with me deserves what they get.#    University of Maryland Baltimore County
#################################	    alex@umbc3.umbc.edu

jmm@eci386.uucp (John Macdonald) (05/13/91)

In article <75230@brunix.UUCP> cgy@cs.brown.edu (Curtis Yarvin) writes:
|In article <110@fbits.ttank.com> Mariusz@fbits.ttank.com (Mariusz Stanczak) writes:
|>The microkernel idea is just few years old(new), 
|
|The idea is about ten years old.

Actually, the *idea* is more than 2 decades old.  A commercial
implementation of this particular idea has been available
since the late 60's (you may have heard of the company that
developed it, they're still around, still selling the virtual
operating system, and they're blue).  We can probably assume
that the idea predates this point in time at least.

I restrained myself from quoting Curtis' comment about missing
a decimal point - he isn't quite that far out.
-- 
sendmail - as easy to operate and as painless as using        | John Macdonald
manually powered dental tools on yourself - John R. MacMillan |   jmm@eci386