Path: utzoo!dciem!nrcaer!sce!graham
From: graham@sce.carleton.ca (Doug Graham)
Newsgroups: comp.os.minix
Subject: Re: Assorted questions
Message-ID: <879@sce.carleton.ca>
Date: 18 Jul 90 05:01:16 GMT
References: <628@philica.ica.philips.nl>
Organization: Systems & Computer Eng. Dept.,Carleton University,Ottawa,Canada
Lines: 83

In article <628@philica.ica.philips.nl>, adrie@beitel.ica.philips.nl (Adrie Koolen) writes:

> The method of structuring Minix into a bunch of processes reflects the way
> of thinking of the programmer.

This is almost a tautology no?

>				The way of assigning policy matters to MM
> and FS and implementation matters to the kernel eases porting and debugging
> a lot.

I don't disagree with this. But I think this statement would still be
true if MM, FS, and the "system" task were not implemented as tasks,
but rather software subsystems in the usual sense. Note that I'm not
advocating mixing the high level software with the low level software
into one big jumble.

>       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).

What might those appropriate actions be? In the Minix that I have,
MM, and, to a lesser extent, FS, are intricately involved in exception
handling. If it was one of those tasks that incurred the exception,
what then? Even if there is some advantage to having a good part of
the O/S run in user mode, could the switch to supervisor mode not then
be done via a normal trap, rather than a message pass, and context switch?

One of the things that bothers me about Minix, are the time wasting checks
scattered about in the code that do something like:

   if (source != MM_PROC_NR) return (ERROR) /* Only MM may make this call */

This is necessary, because, as set up now, the different peices of the
O/S communicate between themselves using the same message passing mechanism
that the user processes use to communicate with the O/S. There is nothing
preventing a user process from sending a message to the SYSTASK for
example. IMO, even if the O/S is implemented internally using message
passing, this should not be visible to the user, i.e. he/she should not have
to name a destination task when making a system call. If Minix wants to
internally vector the call off to a task, it should have an internal
table telling it which task to pass the call off to. This solves the
problem above, and also, more importantly, makes it possible to change
the kernel implementation without having to change the libraries, and
recompile all the user programs.

>     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.

I implemented almost exactly this for a real time system I was working
on. The only diffence was that the determination of which file server
task to use, was done at open time, not on every call as you suggest.
This had more to do with the limitations of the RT executive I was
using than anything else. Anyway, I think this approach makes some sense
for a distributed system, but for a uniprocessor system such as Minix
(am I being too short-sighted here?) it is just unecessary overhead and
complexity. Note that your solution does not solve the disk arm scheduling
problem. As long as there is only a single winchester task, it will get
only one request at a time. Or do you plan to clone these as well?

Note as well, that preventing one FS thread from preempting another,
is not enough to guarentee the consistency of the FS data structures.
A thread would still have to lock critical data before possibly blocking
on disk I/O. Actually, having got as far as having multiple FS threads,
you're now faced with exactly the same mutual exclusion problems that
standard Unix has. You could consider the FS thread as being the equivalent
of the Unix kernel context for the user process. So how do do this
locking of data structures in Minix? Where does the FS thread wait
until the lock has been released?

----
Doug.