On Sep 13, 1:38 pm, Ben Gras wrote:
> All,
>
> On 2007-09-13, Matej Kosik wrote:
>
> > Unfortunately, I am not able to upgrade from Minix 3.1.2a to SVN
> > trunk. Whenever I do that, I end up with unmountable root filesystem.
>
> > /dev/c1d0: No such file or directory
>
> Upgrading from 3.1.2a to current is very rocky, yes.
>
> > If you generate new CD image (or even better, publish a QEMU image), I
> > will be able to check it.
>
> Bleeding edge images are here:
>
> > You say that the above program when loaded
> > as a driver will not cause denial of service after someone requests
> > services of such a that driver?
>
> It depends on how robust the server that does the request is to message
> protocol violations. Currently, VFS/MFS are not robust (hanging
> filesystem processes resp. device drivers will currently hang VFS/MFS),
> but e.g. INET should be, hence Philip's example.
>
> =Ben

You are right. I have checked that because I wanted to be sure about
it. The above trivial (but buggy) device driver hangs the whole OS and
thus it is (from very strict point of view) part of TCB. Do you think
that this kind of problem can be solved with the present communication
primitives?

Note that Erlang has a construct

receive
pattern -> action
pattern -> action
after
action
end

Maybe something similar could be added to Minix too but it would be
elegant (although Erlangers like it). Playing with Erlang I realized
how the idea of named processes is bad. To be able to do RPC it is
necessary to emulate "selective receive" with invening "unique" tags.
This is ugly. In Pict we have communication over channels (rather than
communication between processes) and this gives the programmer a lot
of freedom. A request can be received on one channel whereas client
can specify where he wants the reply. The server might do something
and dispatch the request further asynchronously and immediatelly
devote itself in serving next request. Finally, someone sends proper
answer through proper channel to the original client.

However, by studying Minix I have realized that your organization of
processes (almost) has some hidden value. Processes (in Minix almost
but not completely) form partial ordering---from the point of view who
is allowed to activate whom via RPC. Activation from the bottom are
always asynchronous. This way deadlock is excluded (albeit
interference still could happen if things are not programmed well). In
Minix this is almost true. Not completely because between PM and FS
happens some kind of weird communication that does not obey these
rules.

I wonder whether it is possible to organize OS that follows such
ordering of processes without exceptions. OS is a small world so I
believe something similar is possible.

In my experiments, wherever possible, I use asynchronous message
passing. Handlers of IRQs (in kernel space) or UNIX signals (in user
space) must not be function abstractions (that should be synchronously
called). They must be process abstractions (that, when sent an
appropriate signal message start to run. This does not block the
sender). This way the more trusted parts are guarded from handlers
that "do not return".

All,

> You are right. I have checked that because I wanted to be sure about
> it. The above trivial (but buggy) device driver hangs the whole OS and
> thus it is (from very strict point of view) part of TCB. Do you think
> that this kind of problem can be solved with the present communication
> primitives?

Yes; for the VFS example, a fully asynchronous VFS that uses
asynchronous send should be able to cope with any kind of filesystem
misbehaviour. As Philip noted in an earlier reply to you, there are
plans to actually do this. As I see it, this is no limitation of minix,
but a server implementation issue.

=Ben