Organization [dpm1] [djg15] [djg16]

[David Garfield]

"> > > " Is Dennis
"> > " Is David
"> " Is Dennis

> > > (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.

I didn't say it would always make sense, but if you write line buffers
to a serial port attached to a printer, it can make sense.

> 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.

Actually, I think it should be a print manager CLASS which buffers
activity until a print manager object is closed, and then sends
everything at once to the real printer interface object.  One more
class for the hierarchy.  Remember, lots of stuff, not just the
devices, are classes.

> 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 changed the root from device to object with good reason.  This is
the class hierarchy.  An entry here means a class, not an object, not
a device.  I agree that the class that looks like a stream interface
and maps to a keyboard and video object does deserve a process of its
own, but this is why I am arguing that objects are not processes /
processes are not objects.

As for "our mucketmockup", ok if this is "our"s, how do I see it?  Or
should that have been "my mucketmockup"?

> 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!


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