Path: utzoo!attcan!uunet!mcvax!hp4nl!phigate!prle!prles2!cstw01!meulenbr
From: meulenbr@cstw01.prl.philips.nl (Frans Meulenbroeks)
Newsgroups: comp.os.minix
Subject: Re: Future of Minix
Message-ID: <574@prles2.UUCP>
Date: 19 Jul 89 06:56:29 GMT
References: <573@prles2.UUCP> <2903@ast.cs.vu.nl>
Sender: nobody@prles2.UUCP
Reply-To: meulenbr@cstw01.prl.philips.nl (Frans Meulenbroeks)
Organization: Centre for Software Technology, Philips Eindhoven
Lines: 63

In article <2903@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
]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.

I could not either. However, I am getting a little bit irritated by not
being able to do an ls in /us/src/lib, and by fsck always complaining
about it being a huge directory.

The only two splitups that come in mind are:
- fork off games stuff and system stuff (so create sections 1/6/8)
- investigate whether there is already a workable posix draft on
  commands and split in posix/additional.
  If posix does not have something useful perhaps X/Open can be used
  instead.
]
]>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.

Yes, but declaring them all would make things more visible.
Also, personally, I'd prefer to have all local routines declared
forward, not just the one's that are used before declared.
This also gives a fast overview of what to expect in a file.
]
]>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.

currently every routine which needs an external int function just
uses it, and presto. I would prefer a declaration just like for non-int
functions. However to avoid the scattering of lines like:
extern int send();
I think I'd prefer a file, say fs.h, which includes all declarations of
all exported functions.
]
]>4 explicitly type all subroutines
]You mean like void foo() vs. int foo()?  I suppose I could.  The ACK compiler
]accepts void.

Yes, thats one thing. But what I actually meant was avoiding declarations
without any typing at all. This happens on some places. I know if you
declare a function without a return type, the return type defaults to
int. However I do not like it. It does remind me too much of Fortran
where the first letter of an undeclared variable determines its type :-)
]
]>5 Use function prototypes in all forward declarations.
]>ARG
Is this a yes or a no ? :-)
]
]Andy Tanenbaum (ast@cs.vu.nl)


Frans Meulenbroeks        (meulenbr@cst.prl.philips.nl)
	Centre for Software Technology
	( or try: ...!mcvax!phigate!prle!cst!meulenbr)