Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!inria!axis!philip
From: philip@axis.UUCP
Newsgroups: comp.os.minix
Subject: Re: Disk Scheduling
Message-ID: <199@axis.UUCP>
Date: Sat, 7-Mar-87 10:47:13 EST
Article-I.D.: axis.199
Posted: Sat Mar  7 10:47:13 1987
Date-Received: Mon, 9-Mar-87 04:05:20 EST
References: <236@inuxf.UUCP> <108@illusion.UUCP> <239@inuxf.UUCP>
Organization: Axis Digital, Paris
Lines: 58
Summary: One way to do it ...

> How does one go about adding a queue and a seperate task that will service
> that queue independant of other processes.  With the existing message passing
> scheme the driver must recieve() and then send() before going into another
> recieve().  This means the driver cannot recieve() and queue, recieve() and
> queue, etc.  Or am I missing something entirely?

The existing driver is nice and simple - ideal for its intended purpose
of being part of an operating systems course, where it is esential that
the functionality is not obscured by complex algorithims.

The existing structure (simplified) is:

	while (read message)
	do
		set up disc controller
		set GO bit

		read message from hardware (interrupt)

		send reply to the awaiting process

	done

On a heavily loaded system (loaded with disc activity, that is),
the driver will spend most of its time waiting for the message
from the hardware (an interrupt).

It should be possible to modify this structure slightly to allow the
maintainance of a sorted disc access list.

	while (read message)
	do
		switch on type of message:

		case read:
		case write:
				insert call into list (sorted)
				if pointer to currently executing access
				is NIL, set up controller and write GO bit.

		case hardware:

				if pointer is NULL then error(Random interrupt)
				else
					test controller status
					re-issue read/write if need be
					else send message to waiting process

				if list is not empty, set up and initiate
				next read/write
	done

Not having studied the sources in the book VERY closely, I think that
the above scheme would work. Obviously, the structure is more complex
and would probably not be suitable for an introductory os course.

When (and if !) my sources arrive, I may try re-writing the driver as
described above (unless some kind person saves me the trouble).