Path: utzoo!attcan!uunet!mcsun!hp4nl!phigate!philica!adrie
From: adrie@philica.ica.philips.nl (Adrie Koolen)
Newsgroups: comp.os.minix
Subject: Re: Recap on past 2 weeks
Message-ID: <641@philica.ica.philips.nl>
Date: 2 Aug 90 14:04:35 GMT
References: <7217@star.cs.vu.nl>
Reply-To: adrie@beitel.ica.philips.nl (Adrie Koolen)
Organization: Philips TDS, Innovation Centre Aachen
Lines: 22

In article <7217@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>With relatively little effort, the disks could use this existing mechanism.
>When FS sends a disk driver a message, if the disk driver didn't happen to
>have the block cached internally, it could store the request in its tables,
>and return a SUSPEND message immediately.  FS would react the same way as with
>TTY.  I could probably even use the same code.  When the disk did the work,
>it would send a message to FS, same as the TTY task now does.
>
>This scheme would allow multiple disk requests pending at the same time, but
>would not require changing FS very much.

When a task issues a SUSPEND reply, it specifies the number of the user
process to be suspended. When reading/writing blocks, the FS specifies
itself as the process for wich I/O must be done! This brings me to the
standard problem: the FS issues requests to the (block) tasks for user
processes AND for the FS self. The former could be suspended but suspending
the latter would require a lot of rewriting of the FS. Maybe I am a little
to negative, but a stated FS doesn't seem easier or more stable than a
multi-threaded FS.

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