Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!mcvax!hp4nl!botter!star.cs.vu.nl!ast
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: Future of Minix
Message-ID: <2903@ast.cs.vu.nl>
Date: 18 Jul 89 18:49:25 GMT
References: <573@prles2.UUCP>
Reply-To: ast@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 27

In article <573@prles2.UUCP> meulenbr@cstw01.prl.philips.nl (Frans Meulenbroeks) writes:
>Some things which might be considered for the next release of Minix:
>1 splitting the lib and commands directories.
In principle I have no objection, although I like the idea of being able
to get all the commands in one ls.  Another possibility is running up the
size of the exec buffer from 2K to 3K or 4K.  If I were to split lib,
what would be a good division.  The system calls, e.g. fork(2) could go
in one directory, but I can't think of any logical division for the rest.
For commands, I can't think of any logical division at all.  Just splitting
[a-m] and [n-z] doesn't seem real exciting.

>2 declare all local subroutines forward in the various files
I think this is done for those cases where they routine non-ints.  For
things returning int, it shouldn't matter.

>3 create an include file for kernel, mm, fs which contains all
>  global subroutines. This file should be included by every module.
I don't understand what you mean.

>4 explicitly type all subroutines
You mean like void foo() vs. int foo()?  I suppose I could.  The ACK compiler
accepts void.

>5 Use function prototypes in all forward declarations.
>ARG

Andy Tanenbaum (ast@cs.vu.nl)