Devices classification tries to define some abstract class of device which makes device programming easier. No wonder for the filesystem whether it uses a scsi or IDE disk: it just wants to read or write sectors of the disk, and this is just what the "block device" interface provides. Here comes a small list of classes that might be found in Clicker.
This classification is based on the way the system and the device can exchange datas.
This is the simplest device. It can be seen as a pipe where bytes of datas are pushed to the device. Most input devices like keyboard and mouse match this model.
An important feature of the character device is that once bytes have been emitted, you cannot cancel them, and once a byte has been read, it cannot be read again.
primitives: putchar(char):void, getchar():char
events: device ready for more writing - a byte is available for reading
||The block device mainly fits storage
devices. Datas can only be transferred by a fixed amount called the block
size. Moreover, to access one of the blocks, the system must give the
block identifier for the piece of data to be read/written.
primitives: read(blockid, &buffer):status, write(blockid, &buffer):status
events: last operation finished.
||The stream device
expects datas to be transmitted at a regular (and usually constant) bitrate.
The system will usually prepare datas in a buffer while the device is consuming
the last transmitted datas. When the device is done with the datas it has,
it will notify the system that it will now switch to the next block. Any double-buffer
device can fit this model (soundcard, framebuffer, etc.)
primitive: start_transfer(...), system_ready(&buffer), stop_transfer
events: done_with_datas(&buffer), underrun, overrun
The stream device is something that does not appear in legacy unices. It is however a powerfull tool for every multimedia application, as it has inherent real-time behaviour. If the system cannot produce/consume device bytes at the expected rate, the driver will issue an underrun event. If it gives too much datas at once, an overrun event occurs. These events can help the system re-negociating the rate in some case.
The char/block/stream interface is only a part of a device driver. If you're using a disk, you also plan to be able to know its storage capacity, and if you're using a mouse, you'd like to know how much button it has ... this is what i would call the 'infos' interface. Every device will come with its information interface that gives the system the opportunity to ask such informations.
You will for sure notice that the kind of relevant informations higly depends on the kind of device you're using. So i guess those device informations could be seen as a sort of classes, so that every hard disk device provide coherent parameters regarding to other hdd.
The third and last interface is the control interface, that will give the system access to miscellaneous functions like ejecting CD, recalibrate joysticks, switch video mode, flash keyboard leds, etc. Such interface is very specific and will usually not be shareable with other device, even within the same data-access class
Note that highly specific informations like typematic rate (for a keyboard) or led state should better be a method for the control interface than for the infos interface.
Every device will be described in an entry of "system.devices.*" of KDS. sub-sets will be created for every "class" of devices (like system.devices.disk.*, system.devices.input.*, etc.) Within a device set, each device will have a symbolic short name (like hda1 for the main disk drive, etc.) That name is provided for quick research by programs, not for humans. A human-readable name (based on the vendorString, for instance) will be created by the toString method of the kds Object.
Among other, each device will receive, by registering into kds://system.devices.*, a unique device identifier, which can be used for identification when calling a service.
Each piece of information about the device will be stored as a part of the kds object and will define the "infos interface" of the device. How such objects will be implemented is not yet stated, so for now, it should simply be added into a structure that will be registered to the proper system.devices.