Organization [dpm1] [djg15]

[David Garfield]

On Wed, 31 Mar 93 15:00:45 PDT, "Dennis Marer" <dmarer@td2cad.intel.com> wrote:

[...]
> My plan is set for the next couple of weeks, and I'd like to shift gears a bit
> and set you all into a different line of thinking for a while.  At this point,
> I'd like to ask you to trust me and assume the kernel is defined enough to the
> point that we may start design of the rest of the system.  I'd like to turn
> your brains away from the kernel for a short while and start thinking about
> what resides on top of it.  Namely, as Andreas suggested, the devices.  I've
> grouped things together more into related areas, as shown below:
> 
> 
> User Input Devices
> ------------------
> 
>     Text input (keyboards, speech recognition)
>     Position input (mice, touch screens, etc)
> 
> User Output Devices
> -------------------
>     Video output
>     Hard copy (Printers, plotters, faxes)
> 
> Mass Storage Devices
> --------------------
>     All types of disk drives (low level block access, floppy, hard, networked)
>     Filesystems (HPFS, DOS, etc, etc, ???)
> 
> Communication Devices
> ---------------------
>     Serial
>     Parallel
> 
> Networking Devices
> ------------------
>     Networks
> 
> Maybe I'm missing a few, or the groupings aren't quite right, but that's not
> too important.  What is important is the concept of a device as an object, and
> how it is similar to objects in its group.  For example, why could both the
> serial and parallel devices utilize the same interface?  Each would be a
> descendant of some 'communication device' object but implement its methods in
> a way pertinent to itself.  Similarly, both hard copy and video devices might
> share the same interface to simplify WYSIWYG output when the GUI is developed.
> (Oh...I didn't put the GUI on here because its not a device.)

Just because it isn't a device doesn't mean it doesn't deserve equal 
consideration....  In fact, most of the system should be non-device 
classes.

> Here are some of the steps I see in defining device objects:
> 
>     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.

>     2. Relation to other devices
> 
>         How would this device work in conjunction with other devices?  Would
>         it use other devices?  Would other devices use it?  How similar is it
>         in functionality to other devices?  For example, a network device might
>         be able to use either a standard serial port or FDDI hardware without
>         changes to its internal structure.  This would be both of these types
>         of communication devices should be designed with identical interfaces.

Classes implementing an objects functionality have the ability to 
reference other objects.  Thus the IP class references a FDDI hardware 
object or a SLIP or PPP object which in turn references serial port 
object.  Of course, someone could go a bit crazy and put a SLIP object 
on top of a TCP object, but...  

>     3.  What special needs does the device have?  Can these be accomodated by
>         the generic kernel or do special extensions need to be built in?

Nothing should require extensions to the kernel.

>     4.  How will device contention occur (transparently to the user) in multi
>         user devices? 

It needs to occur inside 

>     5.  What will the interface to the device be?  For data transfer devices
>         will this be block or stream oriented data?
> 
>     6.  How can devices with similar interfaces be better grouped together to
>         minimize our work?  For example, could all data transfer devices (like
>         disk drives, and network devices) use a common ancestor to handle some
>         of the more common functionality?

If we don't do this, we aren't much better that Unix.

> Just thinking about it, here's a sample heirarchical structure of devices. I
> just spent a few minutes on this, so its nothing concrete, just an example of
> how things might be structured:
> 
>         device
modify:   object
>             dataTransfer
>                 blockData
add:                  communication
add:                      Ethernet
add:                          various ethernet cards
add:                      FDDI
add:                      IP            (non-device object)
add:                      UDP           (non-device object)
add:                      SLIP          (non-device object)
add:                      CSLIP         (non-device object)
>                     massStorage
>                         floppyDrive
>                         fixedDrive
>                             Winchester
>                             SCSI
>                             networkDrive
>                             etc.
>                         CD-ROM
>                         floptical
add:                      ramDisk
add:                      file          (non-device object)
        A file has basically the same capabilities of a mass storage 
        device with the addition that it is variable length.  Anything 
        you can put on a device you can also put in a file.  
add:                      partition     (non-device object)
>                 streamData
>                     communication
>                         serialPort
>                         parallelPort
>                         modem
(another non-device object)
add:                      terminal      (non-device object talking to 
                                        a userInput/characterBased and 
                                        a userOutput/video) 
add:                      TCP           (non-device object)
>             userInput
>                 characterBased
>                     keyboard
>                     voiceRecognition
>                 positionBased
>                     mouse
add:                      busMouse
add:                      serialMouse   (non-device object)
add:                      ps2Mouse      (keyboard user?)
>                     touchScreen
>             userOutput
>                 hardCopy
>                     printer
>                     fax
>                 video
>                     VGA
>                     superVGA
>             audioOutput
>                 sampled
>                     soundBlaster
>                 note
>                     MIDI
>                     etc...
> 
> Does anybody want to officially document this structure and keep it current?
> Or restructure it?  Like I said, I only spent a few minutes on it...

By the time get the system built there should be several hundred 
entries here.  It would be good to start considering how this stuff is 
given to the kernel.  In the hierarchical form.


David

P.S.  Dennis, try to avoid tabs...

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