Driver design question

[Bill Frantz]

Sorry to be so slow replying, my life has been busy.

At 13:20 6/30/95 -0400, Jonathan Shapiro wrote:
>Okay.  A question has arisen in the area of driver design, and I'ld
>like some input on it.  
>
>There are a number of places where the disk drivers on a PC must
>perform some hideously complex operations.  The most notable case is
>probably mounting the drives, where reading the partition table
>involves a complex sequence of events.  For the most part, the
>complexity arises because the drivers are asynchronous; there is an
>in-built assumption in the current implementation that the stack is
>not preserved from one invocation to the next.
>
>While all of the cases that I have encountered so far can be captured
>in a state machine, doing so decidedly obscures the intent of the
>code.
>
>An alternative design would be to dedicate an in-kernel thread to each
>disk controller, and allow that thread to have a stack.  Under this
>design, the disk driver code assumes that it should behave
>synchronously, and that the stack is preserved.

There is no real reason not to have a set of kernel stacks for kernel
tasks.  However, I still think you need to make proofs about the kernel
running out of storage.  These would involve no, or strictly limited
recursion, a finite (and managable) number of tasks etc.

Why are all the device drivers in the kernel?  (IMO device drivers are evil
and should be treated with great suspicion.  Since they normally run as
part of kernels, they are an obvious place for Trojan Horses.)  If they are
not a part of the kernel, then this problem disappears.

>To start a disk I/O,
>the kernel queues the I/O request on the appropriate device queue, and
>(if it isn't already running) performs a voluntary context switch into
>the thread associated with the controller.

I would think you would want to have a queue of pending work which is
checked by the controller thread when it is not busy doing something else. 
You could even arange for the stack to be empty when there was no work. 
The problem with these stacks is that you are tempted to multiply them. 
First one/device driver, then one/device, and finally one/request which
complicates your storage proof.

>
>The controller thread then runs until it must wait for some completion
>event.  When it must wait, it voluntarily relinquishes the processor
>to whatever thread should run next.
>
>These threads would, as a general rule, run in the same address space
>as the kernel.  An exception to this rule would be the BIOS disk
>driver. 

All the more reason to have it run in a domain.


>Cons: 
>  ...
>
>  o Things get more complicated on controllers whose units can operate
>    in a "disconnected" fashion - notably SCSI.  The impact of this is
>    unclear.  I seems to me that one can still fall back to the state
>    machine approach on such controllers.

If you are going to have to use state machines anyway, do you gain anything
by having the kernel thread mechanism?


-----------------------------------------------------------------
Bill Frantz                   Periwinkle  --  Computer Consulting
(408)356-8506                 16345 Englewood Ave.
frantz@netcom.com             Los Gatos, CA 95032, USA