Driver design question

[Bill Frantz]

At 13:46 7/13/95 -0400, Jonathan Shapiro wrote:
>...
>
>Given this, I can really only see two reason not to make the disk
>drivers be ordinary domains.  Both of them reflect issues in the
>underlying architecture rather than issues with the idea.
>
>        1) user/supervisor transition time
>        2) address space switching overhead.
>
>On some architectures (okay, okay - I have x86 on the brain at the
>moment) switching from user to supervisor mode takes a long time, and
>may be necessary in order for the program to have enough authority to
>manage a device.  If the process has to be in supervisor mode to talk
>to the devices, this is an issue.

If we had done domain disk driver on the 370, it would have used the
standard (and MUCH later developed) generalized channel program support. 
The 88K would have used the (never developed) generalized SCSI support.

>
>...
>
>The more challenging problem on most architectures is the cost of
>address space switching, which is usually not cheap.  In a funny sort
>of way, one can think of the kernel as a "parasitic" program that can
>run in any address space that is handy.  A useful consequence is that
>one doesn't need to change the address space when entering the kernel
>if the architecture does not facilitate that.  On such architectures,
>there would seem to be real advantages to running disk drivers as
>parasitic in the same sense - in which case they almost certainly do
>NOT want to be ordinary domains.

Depending on your implementation, you can have the map you load when you
dispatch the domain be the same map as the kernel (losing all the
advantages of isolation), and you can probably contrive to even dispatch it
in supervisor state, making it a real kernel thread.


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