Path: utzoo!attcan!uunet!mcvax!botter!star.cs.vu.nl!ast
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: V1.3 posting #1 - USER_GUIDE
Message-ID: <776@ast.cs.vu.nl>
Date: 1 Jun 88 09:02:08 GMT
References: <762@ast.cs.vu.nl> <967@ndsuvax.UUCP>
Reply-To: ast@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 89

In article <967@ndsuvax.UUCP> ncoverby@ndsuvax.UUCP (/dev/tty) writes:
> I had one problem un-sharing the library diffs
Note to others:  It would be helpful to be more specific than this.


>I was unable to locate the "fgrep.c" or "tty.c" files listed in the "commands"
>listing. The tsort.c and lorder.c that I have require several other files
>to compile; those were not listed in the commands source directory, I 
>don't belive. What should I use? (I have the posting from a few months ago).
>Sed.c seems to also be different than the one I have; it also is multiple 
>files.
fgrep and tty are in posting #10.  tty.c needs a subroutine I have lost (help!)
I have slightly lost track of lorder and tsort due to the many fixes. Perhaps
a new posting by the author?
The new sed.c (single file) is a debugged version
of the old multiple file version.  Throw the old one away.



>I had lots of trouble patching the diffs for malloc.c 
The two mallocs are almost unrelated.  The new one is much faster.  It uses
a linear algorithm.  Still, after making the diffs, I ran fix to verify that
the diff output could be fix'ed.  If patch fails, try fix.



>There were references to the "minix" include directory.
It is new.  /usr/include/minix contains links to files in 'h'.  See posting #2.



>Nor could I find where "lib.h" should go
It goes in lib.



>When compiling the library, I found that I needed a "-I." on the cc line  <
>in run.  This could be because I have the 1.1 C compiler.  Amoeba.c was 
>uncompilable because two required header files, amoeba.h and amparam.h    <
You may also need -Di8088.  amoeba.h and amparam.h are in the amoeba dir.
That will come in a couple of weeks.


> Fopen.c gave me problems on line 34 with 'errno' and 'ENOENT' undefined etc
Please try to fix it and post something.



>Since Andy is going to stick with pretty much the Minix described in his
>book, is anybody working on organizing a "enhanced" Minix consisting of
>the enhancements from the nework, like process groups, message queueing,
>etc.?
Somewhat grudgingly, I'm increasingly willing to add non V7 utilities, but
I am hesitant to change the kernel.  It actually works now, and the mean
time to failure on my system is many weeks, if not months.  Johan put
process groups and some other stuff in, although it is currently #ifdef'ed.
As a bare minimum, wait until I post the kernel in a few weeks, and then
see what you want to add.  There have been some many modifications
proposed, many of which are in conflict, and more of which are highly
questionable in a PC environment.  Other proposed changes are nonportable
(protected mode on a 286 won't work well on a PC, or later on a PS/2 model
30; although the PC may die off in a few years, the PS/2 model 30 will be
around until the next century).

In addition, the networking code has had a major impact everywhere.  This
has resulted in a new top-level directory, amoeba, that contains an ersatz
kernel.  Big changes to anything in kernel will also imply parallel changes
to amoeba/kernel.  

To the extent that there are some changes that are universally popular with
everyone except me, there is something to be said for having enough
discussion in this group to try to reach a consensus, and then converge on
a set of changes so that we don't get 12 different ways to use protected
mode.  Preferably such changes should be modular.  Replacing an entire
subroutine is usually cleaner than putting in 3 #ifdefs.  When you see FS
and MM, you will see how Johan put in the Atari stuff.  While no #ifdef'd
code is really readable, by and large what he did can be considered a
good model.  If a new feature can be added by two or three #ifdefs, one of
which contains 3 pages of subroutines at the end of some file, people can
easily compile without the flag or remove the code altogether.

On the other hand, if there are small, working, useful commands or library
routines I have missed, there is a reasonable chance that this is an
oversight.  If somebody in netland is minoring in Library Science, you might
try to collect a list of all commands and subroutines that have been posted
that are not currently in 1.3.  That would be an interesting item to 
discuss on the net.

Andy Tanenbaum (ast@cs.vu.nl)