Organization [dpm1] [djg15]

[Dennis Marer]

> > Is Dennis
> Is David

> > (much stuff deleted)

>     1. Classification (Single vs. Multiple user)
> 
>         Can this device be used by more than one user at a time?  A serial
>         port, for example, could only support a single user which greatly
>         simplifies its interface and internal workings.  Disk drives need to
>         be accessed by multiple users, so their interface needs to accomodate
>         these needs and their internals become much more complicated.
>
> I must disagree.  EVERYTHING should support multiple users.  In the 
> case of a serial port, there is no reason why several dozen different 
> programs cannot all be writing strings of data to a log printer on a 
> serial device.  Offhand I can think of only 1 device (piece) that 
> cannot have multiple users is the PC/AT keyboard drivers ResetCPU 
> function, which, if a call gets past security checks, NEVER RETURNS 
> AND TAKES OUT (terminates with extreme prejudice) MOOSE.

If several dozen different programs try to access the serial port at once,
what appears at the other end would be garbage.  Without knowing what's
connected to the other end of the serial port, there would be no way to
logically manage access by multiple processes.

If, for instance, you wished to connect the printer to a serial port, there
would need to be some process (like Print Manager in Windows) to manage the
serial port.  When it started, it would acquire the serial port, thereby
making it unavailable to all other processes.  It could then logically know
how to manage the hardware.  A device like the serial port is a very general
purpose device, and the low level access to it should involve only minor
management.  And buffering or contention access is usally dependent on what's
connected to the other end.



Those are good suggestions for new entries to our device heirarchy!  There
surely will be hundreds when we're through.

I tinkered more with our mucketmockup, trying to write a simple device
driver for a text screen.  I discovered there were absolutely no advantages
to this device driver being a process, i.e. it does not need any periodic
use of the CPU time except to service interrupts and so on.  Can anyone think
of any reason a device driver should be a process?

I'm guessing possibly we could make a device driver a shared object owned by
the kernel.  (Their data would reside in the kernel's memory space...?)  I
don't know...maybe y'all have some better suggestions!


			Tschuess,

			    Dennis
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@snoopy.sra.com