Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!phigate!philica!adrie
From: adrie@philica.ica.philips.nl (Adrie Koolen)
Newsgroups: comp.os.minix
Subject: Re: Assorted questions
Message-ID: <628@philica.ica.philips.nl>
Date: 16 Jul 90 11:35:26 GMT
References: <877@sce.carleton.ca>
Reply-To: adrie@beitel.ica.philips.nl (Adrie Koolen)
Organization: Philips TDS, Innovation Centre Aachen
Lines: 59

In article <877@sce.carleton.ca> graham@sce.carleton.ca (Doug Graham) writes:
>...
>If, for example, MM wants to fiddle with the stack of a process in order to
>deliver a signal to it, it must send a message to the "system" task telling
>it to do so. The "system" task carries out the request, and then replies
>a status, at which point MM continues. But this is really nothing more
>than a procedure call, it does nothing to enhance paralellism. All this
>message passing stuff only serves to obfuscate the code. The system task
>could just as easily be made a passive collection of procedures. As well
>as making the code easier to follow, this would also eliminate the message
>passing, and context switching overhead.
>...
>    Now for my final question: are there any real advantages to structuring
>an OS as a collection of co-operating tasks as in Minix?  I don't see
>paralellism as being the answer either; in fact, the structure of Minix
>impedes paralellism in a lot cases. For example, FS is a major bottleneck.
>If one process is waiting for a sector to be read from a floppy, other
>processes wanting to access the winchester, or tty, wait. You can also
>say goodbye to all those fancy disk scheduling algorithms. In Minix,
>the disk driver only gets a single request at a time, so it's scheduling
>job is pretty simple. I think Unix has it right: the kernel should be
>a passive entity which carries out requests in the (kernel) context of
>the calling process. The Unix sleep/wakeup mechanism seems a bit weird
>(How come it's never mentioned in the textbooks alongside semaphores,
>monitors, and message passing), but it also seems quite effective.
>------
>Doug.

The method of structuring Minix into a bunch of processes reflects the way
of thinking of the programmer. The way of assigning policy matters to MM
and FS and implementation matters to the kernel eases porting and debugging
a lot. The structure of Minix helped me porting it to the SparcStation 1,
where the MM and FS contain NO assembly routines and run in the processor's
user mode. They also run in separate contexts, so neither the MM nor the FS
can access memory of other processes directly. When there's a fault in the
MM or FS, e.g. a bus error, it is trapped and reported to the kernel, so
that appropriate actions can be taken. The kernel processes run in
supervisor mode and can do nasty things like program the hardware (e.g.
remap physical memory).

The problem with the one-threaded FS is mentioned regularly in this
newsgroup and I agree: it has to be fixed. On my SparcStation, I use a
multi-windowed TTY driver and I suffer the single-threadedness
continuously when in one window, a `make' is started, or another disk-
intensive process, like `find' or `tar', and I want to edit a file in
another window. The best solution to this problem would be to re-implement
the FS as a 'stated' FS which returns to the main FS loop to send or
receive messages. This approach requires quite complicated changes in the
FS. An easier method would be to create e.g. 3 FS threads. A FS, which
waits in the main loop for a message is said to be free. User processes
send messages to the FS, not knowing that there are 3 instances of the FS.
A free FS is selected, which handles the request. When it sends a message
to a task, the task replies to EXACTLY that FS thread. A FS thread cannot
be interrupted by another FS thread, only by tasks. This feature can be
used to garantee the consistency of the FS tables. This way, several
processes can use the FS to access different tasks concurrently.

Adrie Koolen (adrie@ica.philips.nl),
Philips Innovation Centre Aachen