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)