Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!hp4nl!phigate!philica!adrie
From: adrie@philica.ica.philips.nl (Adrie Koolen)
Newsgroups: comp.os.minix
Subject: Re: FS (was: Re: Assorted questions)
Message-ID: <633@philica.ica.philips.nl>
Date: 18 Jul 90 08:10:40 GMT
References: <877@sce.carleton.ca> <628@philica.ica.philips.nl> <1685@tuvie>
Reply-To: adrie@beitel.ica.philips.nl (Adrie Koolen)
Organization: Philips TDS, Innovation Centre Aachen
Lines: 38

In article <1685@tuvie> inst182@tuvie.UUCP (Inst.f.Techn.Informatik) writes:
>In article <628@philica.ica.philips.nl> adrie@beitel.ica.philips.nl (Adrie Koolen) writes:
>>                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.
>
>It would change the FS a lot, but I don't think it would be very complicated.
>...
>Peter J. Holzer (hp@vmars.tuwien.ac.at)

I agree with you in that the stated FS is more elegant than a threaded FS.
But both solutions have to solve two main problems. The first is that many
messages, sent from the FS to a task, are hidden in a deeply nested function.
For instance, when a process issues an ioctl(), it arrives at do_ioctl() in
fs/device.c, where a message is prepared, sent to the task via rw_dev() and
the results are stored in the reply message for the user process. After the
message has bee sent, the FS has to return to the main loop and when the task
replies, the FS has to finish the request. I think it's best that every time
a message is sent to a task, the address of a function to call when the reply
message is received, must be stored in some table. That way, the FS can
properly handle reply messages, received from tasks.

The second problem is that the FS also uses the tasks for its own purposes.
When reading a file, the FS has to read an i-node and possibly some indirect
blocks to access the data in the file. Each time the FS calls a task, you
must decide where to continue after the reply is received. And believe me,
this requires a lot of rewriting. When Minix was young, the FS contained
quite a lot of small bugs. They didn't occur often, so they were very hard
to find. When you rewrite the FS, be it into a stated or a threaded FS, you
will again create (mostly synchronisation) bugs, that are hard to find. I
say we should go for it, but I think that a restructurization of the FS
will be quite a big job and Andy will not like this (but he will have to,
because Minix will continue to grow and with faster hardware, the
deficiencies of the FS will become more and more apparent).

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