Newsgroups: comp.os.minix
Subject: Re: Minix Project
References: <6s1z21natq.fsf@iago.nac.net> <8i8qb9$2i9$1@fangorn.moria.de>
Organization: Rochester Institute of Technology, Rochester, NY
From: aje9383@osfmail.isc.rit.edu (Andrew Erickson)
NNTP-Posting-Host: grace.isc.rit.edu
X-Original-NNTP-Posting-Host: grace.isc.rit.edu
Message-ID: <39490f4e@news.isc.rit.edu>
Date: 15 Jun 2000 13:15:58 -0500
X-Trace: 15 Jun 2000 13:15:58 -0500, grace.isc.rit.edu
Lines: 116
XPident: news
X-Original-NNTP-Posting-Host: 129.21.4.100
XPident: Unknown
Path: news.adfa.oz.au!clarion.carno.net.au!news0.optus.net.au!news1.optus.net.au!optus!intgwpad.nntp.telstra.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbridge.uoregon.edu!news.acsu.buffalo.edu!bingnews.binghamton.edu!news-nysernet-16.sprintlink.net!news.sprintlink.net!news.isc.rit.edu!aje9383
Xref: news.adfa.oz.au comp.os.minix:35423

In article <8i8qb9$2i9$1@fangorn.moria.de>,
Michael Haardt <michael@moria.de> wrote:
>Mark Gray <markgray@iago.nac.net> writes:
>> That said, I think that the most useful OS project I can see is to
>> introduce multiple filesystem types to the kernel and port either the
>> Linux ext2 file system or the .*BSD Fast File System to minix (I find
>> short file names to be real annoying after using Linux for so long.)
>
>Indeed, a VFS layer would be great.

Indeed.  One concern, to me at least, is performance.  A Minix VFS layer
probably would exist as a separate server, right?  That would mean that
any FS syscall would suddenly have two additional context switches to go
through.  While that may not be a concern for you lucky people running with
1.8 GHz Pentium VIII systems, not everybody is quite so lucky.  Still,
having some sort of a VFS layer would be a really nice thing.

>But there is much more: If you look at NFS, you have a clearly defined
>interface to a file service.  The FS server on the other side is pretty
>messy compared to that.  Make FS stateless and put all the UNIX file
>semantics together with the rest of the common UNIX API from MM into
>a MINIX server.  I further think that the core of memory management
>(hole list maintenance etc) belongs to the kernel.  MM does _much_
>more than memory management and the name MM does not fit really.
>
>Numerous filesystems have been implemented as NFS servers before VFS
>was common, which shows that the interface is pretty generic indeed.
>An FS server with an interface that is similar to NFS would give VFS
>capabilities for free.

Let me see if I understand your idea right.  (If this is wrong, please post
a correction; I think this is what you're saying, but it's not at all clear
to me.)

All the system calls would go to a single server; this would call either a
particular file system through a VFS layer, or muck with the kernel stuff to
get a result.  The interface between this server and the various file system
pieces would resemble NFS.

I don't particularly like this design, for several reasons.  First, although
many file systems have been shoehorned into NFS, it generally doesn't
provide perfectly consistant semantics for any of them.  (Some of that is
due to the network part of things, but quite a bit isn't.  In particular,
cacheing issues tend to make file updates less predictable than just about
anybody would like.)

Second, it seems to me to turn the system into what is essentially a
monolithic kernel with loadable device drivers.  Although this works
reasonably well for UNIX system calls, I kind of doubt it's what is best
for Minix.  (Minix is, first and foremost, an educational tool; I think
making it more monolithic would make it less helpful for that sort of
thing.)

Third, I suspect this would (again) reduce performance.  The single Minix
server would be a bottleneck if many processes were making syscalls
simultaneously; the FS already can be a bottleneck in this way, and adding
more system calls to a single server can't help things at all.  At the very
least, I'd suspect you'd have to make send asynchronous; this would make
programming tasks a bit easier, but makes the actual message passing code
much more complicated and can introduce some subtle race or deadlock
situations which are very hard to find.  (Message queues can eventually fill
up, after all.  It's much easier to find errors when they always cause
deadlock than when they cause it only once in a heavily loaded blue moon.)

I do agree that MM does substantially more than manage memory; it also acts
as a go-between for the kernel and the user programs when no other suitable
replacement could be found.  I think it would be good to move all the
non-file, non-memory, non-network system calls into a separate server. 
(This server would be pretty simple, too; most of these sytem calls are
essentially get_x and set_x sorts of things.)

>As it is, FS and MM are closely coupled.  A different border might
>make the code easier to understand and the result might be a true next
>generation.  At least a previous edition of the book said that FS was
>kind of like a local network file service.  There is some work to be
>done to make that true.

I'm not sure I see how MM and FS are really all that closely coupled, but
I'm open to explanations.  Once the system is running, FS never calls MM
AFAIK; and MM only calls FS for fork() and exec() system calls.  (That is
from the top of my head; I may be forgetting some cruft somewhere.)  With
the semantics of UNIX, I can't see how any design with a separate MM and FS
could avoid coupling with these two calls.

#ifdef SLIGHTLY_OFFTOPIC_RANT
Ideally, we should eliminate fork() altogether; it is one of the biggest
design flaws in UNIX.  "Let's precisely copy this process now so we can,
after five more instructions, replace the image with a new one.  Maybe, if
we sell it properly, people will one day even claim this is efficient."
It's an inherently wasteful model; even with COW et al. a lot of unnecessary
bookkeeping happens in the most common cases.  There are, indeed, some cases
where fork() is useful; but the vast majority of these would be better
served by fork()ing threads rather than processes.  For process creation, a
spawn() call is far more efficient.

"But," the skeptic asks, "how would you be able to set up standard input and
other file descriptors with spawn?"  One solution is to allow processes to
be spawn()ed in a dormant state, and have a few system calls for
manipulating the file descriptors on a dormant, newly-spawn()ed process. 
Once things are set up properly, it could start running.

I've always been a bit incredulous at UNIX fanatics who vociferously claim
how effecient and lightweight process creation is in UNIX with fork().  It
is lightweight compared to some operating systems, where a process carries
with it a lot more associated state (VMS comes to mind), but that is not
because fork() is so great.  Even if the majority of the process image is
not copied, fork() is ineffecient; setting up COW must take longer than not
setting it up.
#endif  /* SLIGHTLY_OFFTOPIC_RANT */

>Michael

-- 
Andrew Erickson
(These are, of course, just my own opinions.  I'm not trying to flame
Michael or anything of that nature.)
