
">" is David Garfield [djg15]
">>" is Dennis Marer [dpm1]

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

 I think it's harmful to differentiate "user" input from any other input.
If a program runs, of course some one told him to !
 This does not mean Text input and Position input should not exist, or be
the same; that's just the opposite: programs should not see any difference
between "direct" or "indirect" user input (after all any input is more or
less indirectly issued from the user: computer don't run on themselves --
yet 8-). The important points are
- from the exterior point of view:what's important is the type, the class
of the object ("device").
- from the interior point of view, what's important is the loloness of the
object, and the randomness of its behavior: the object has more or les
rights on the system, and input speed/value is unpredictable.




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

