Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!bloom-beacon!eru!luth!sunic!mcsun!hp4nl!phigate!philica!adrie
From: adrie@philica.ica.philips.nl (Adrie Koolen)
Newsgroups: comp.os.minix
Subject: Re: Assorted questions
Message-ID: <636@philica.ica.philips.nl>
Date: 23 Jul 90 09:04:09 GMT
References: <628@philica.ica.philips.nl> <879@sce.carleton.ca>
Reply-To: adrie@beitel.ica.philips.nl (Adrie Koolen)
Organization: Philips TDS, Innovation Centre Aachen
Lines: 114

Newsgroups: comp.os.minix
Subject: Re: Assorted questions
Summary: 
Expires: 
References: <628@philica.ica.philips.nl> <879@sce.carleton.ca>
Sender: 
Reply-To: adrie@beitel.ica.philips.nl (Adrie Koolen)
Followup-To: 
Distribution: 
Organization: Philips TDS, Innovation Centre Aachen
Keywords: 

In article <879@sce.carleton.ca> graham@sce.carleton.ca (Doug Graham) writes:
>In article <628@philica.ica.philips.nl>, adrie@beitel.ica.philips.nl (Adrie Koolen) writes:
>>				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.

You've got a big problem here. You can SAY, that the way of structuring an
O.S. results in an O.S., that is at least as readable and understandable as
Minix, is more portable and runs faster than Minix, but in order to prove
that, you have to show that some O.S. has these properties or write such
an O.S. yourself. I don't mean that everyone who makes a comment on some
deficiency has first to solve it before saying something, but you've got to
make your statements plausible.

When you've ever dived in Unix sources, you can see, that they are quite
unreadable. My SCSI task for Minix on the SparcStation consists of two
files, one header and one C file, with a total length of 30KB. The SCSI
driver for SunOS 4.0.3c is contained in 37 files, scaterred over 6
directories for a total of more than 350KB. I know that there are reasons
for this and that the SunOS driver is faster and more versatile than
Minix's, but writing or reading such a SunOS driver requires you to be
more than a `normal' expert.

Give me one good reason why Minix, after it is structured the way Unix is,
won't go the same way of size, complexity and unreadability as Unix has
followed since 1970?! You say, that you're not promoting to throw the
entire O.S. into one big jumble. Can you clarify that? When I look at Unix,
that's just what's going to happen when you structure Minix that way!

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

I don't really feel like discussing the advantages of running as much of
the system as possible in user mode. I guess, that you're deliberately
provoking me.

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

Except for ONE test in mini_send().

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

You've got a point there, but it doesn't happen to much that you've got to
recompile everything.

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

With multiple FS threads, a single task could receive multiple messages
in principle. (There are still problems to be solved but in principle,
it can be done.

>Note as well, that preventing one FS thread from preempting another,
>is not enough to guarentee the consistency of the FS data structures.

I know, but it certainly helps!

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

Good question! I don't have all the answers right now.

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