1. The HIDD Driver Model

The HIDD system embodies a collection of object classes and a shared library providing device driver facilities to the operating system. This chapter describes the operating model of the classes and objects.

It consists of the following sections

Static Model

describing the class structure and properties that make up the static device model.

Object Model

describing the object structure and connection oriented approach of object linkage.

Dynamic Model

examing the runtime behaviour of classes and objects and the lifecycle of a driver.

The HIDD system is broken up into a collection of classes with a strict inheritance hierarchy. A HIDD class implements a device driver for a single device or in rare cases a group of devices and provides an interface for other programs and devices to access.

In order to maintain portability of interfaces across a wide range of hardware this interface will in general not present the raw interface to the underlying hardware. Instead it will present a generic interface that describes many different hardware implementations. This allows for the best reuse of both interfaces and code.

This reuse is enfored by the hierarchy of classes with common device functions restricted to a subsection of the hierarchy. An example of this is disk devices. There are three common disk interfaces available today - SCSI, IDE and floppy. All these devices provide similar functions such as the ability to read and write blocks, and determine the geometry of the disk.

Whilst the implementations of these devices may change the interface does not. A filesystem needs to talk to a disk-like device, but it does not care what the underlying hardware supports -- it only requires the interface. This idea forms the first part of the hiearchy structure - and from where the name HIDD comes. These interfaces provide a hardware independant method of access devices.

hidd

disk

floppy

ide

ram

scsi

virtual

graphics

parallel

serial

If we examine the image above we can see the class tree starts with the hidd class. This is the base class that all HIDD classes inherit from. It provides many useful facilities dealing with initialisation and interaction of HIDDs. A complete discussion of this class is found in the HIDD Class chapter.

Below this there are a number of different classes, each providing a different type of functionality. At the moment the diagram only shows the hidd.disk tree. This contains five entries -- all detailing slightly different kinds of devices. The hidd.disk.virtual is a virtual disk device which provides the ability to address a file as is it were a real device. Similarly the hidd.disk.ram provides access to a fixed size virtual RAM disk.

The hidd.disk.floppy provides access to the normal floppy disk controller. The hidd.disk.ide and hidd.disk.scsi provide access to common hard disk drive implementations.

XXX - Where do CD-ROM's and the like fit in? They are like disk devices, but have some other features that make them different. The Amiga device structure had them as a disk device but with an extra interface. I think that this is probably the way to go. But then you have to differentiate from IDE CDROMs, SCSI CDROMs and the like. In which case you would use hidd.cdrom... but then you have two different interfaces on the same level declaring the same functionality? Does this mean we actually need another level? I hope not. An alternative would be to hidd.disk.cdrom.whatever to emphasise that CD-ROMs are like disk devices, but with a few extra functions?

To complicate matters however the above is only half the story. There is another half of the tree that have different semantics -- providing access to the raw hardware. An example of this type of class would be a SCSI controller -- something that is not always accessed by user programs.

There are however a number of different SCSI controllers available, so there is more specialisation of classes here.

hidd

disk

graphics

parallel

scsi

...

serial

The above picture adds more devices into the class hierarchy. We see now that there is a hidd.scsi subtree containing a number of different SCSI controllers. In this case the hidd.scsi layer provides an interface to the functions that a SCSI bus provides, and the hidd.scsi.* classes provide the implementation for a specific SCSI controller.

This is still not where the story ends. These SCSI controllers may have different ways of interfacing with the computer, and may even have different controllers for different hardware platforms. This introduces another layer of the tree structure.

hidd

disk

...

scsi

...

graphics

parallel

scsi

aha

cont

isa

pci

zorroii

serial

We now see that there are more classes with hidd.scsi.aha as the parent. These provide different versions of the SCSI controller. We can see in the example above that there are three extra classes: hidd.scsi.cont.isa, hidd.scsi.cont.pci, and hidd.scsi.cont.zorroii. These allow us to interface to the controller no matter what form of hardware platform we are using.

hidd.scsi.cont.pci access the controller through a PCI interface -- possibly using memory-mapped IO. hidd.scsi.cont.isa access the device through the ISA bus -- using inb() and outb() style instructions. Finally the hidd.scsi.cont.zorroii device may access the device through the Zorro-II bus, or in some cases it may only act as an interface to the ROM-based Exec device.

The class model as described previously allows the definition of classes providing some degree of abstraction between types of devices (for example disk devices) and the implementation of those devices (disk controllers). It does not however address the problem of connecting the two distinct classes.

Most computer systems have some degree of flexibility about device connections -- you can add, remove or move devices about. This possibility allows for device connectivity to change (from the operating system point of view) every time the operating system starts. This coupled with the dynamic nature of plug-and-play hardware resource allocation gives need for a dynamic connection model.

The HIDD system provides this by describing the connections at the object level. This has two advantages: you can easily reconfigure the connections at any time -- without having to restart the system in many cases, and allows classes to be reused easily to support multiple instances of the same device.

The interconnection model used could be loosely described as being a bus model. All devices are connected to the object that could be considered to be their parent in the hardware of the system.

Take the example of a SCSI disk again. The SCSI disk is connected to a (optionally one of many) SCSI controller. This SCSI controller is connected to some kind of bus -- for example PCI. Finally the PCI bus is connected to some central point of the system that is the parent of all available devices. This is shown more clearly in a diagram.

hidd

disk

...

scsi

...

...

scsi

aha

cont

isa

pci

zorroii

...

It is important here to realise that the connection diagram shown above does not have anything to do with class hierarchies. If we provide a slightly different version of the diagram showing class names this should become clearer.

This is arguably the most important thing to remember when discussing this topic.

The benefits of this connection model are numerous, providing

• an easy way to describe the connections described between the hardware dependant and independant device classes as described in the class model
• a method of allocating and maintaining the resources available on a given bus or controller such as DMA channels, interrupt numbers and I/O address.
• the ability to add and remove devices at any time. This is useful with the increase in hot-swappable devices such as USB devices.
• the ability to enable or disable drivers when their parent device is removed or is temporarily brought off line. You may have a USB hub with a number of devices connected to it, and you decide to unplug the hub. In this case all devices connected to that hub should also be removed.
• XXX more please

A HIDD driver can exist in different states throughout the life of the operating system. The following section describes all the states known about by the root HIDD class.

Unknown

All HIDD drivers start in the unknown state. This is the state of a driver when it has either just been loaded into memory, or when it is inside the kernel, but before it is first initialised.

At this point the driver cannot tell whether the hardware it is tied to exist, and cannot access the device. There will have been no objects created for this driver yet.

From the unloaded state, the only allowed next state is the probed state.

Probed

The probed state is entered after the driver has checked whether the device exists. Normally a driver will only be in this state when the device exists, however kernel based drivers that cannot be unloaded will also be in this state.

Note that the driver still has not allocated any resources and there have been no instances of this driver created. It is possible for the driver to be unloaded from memory in this state, but only under low memory conditions.

Ready

The device will enter the ready state when it has been linked into the system driver list and has allocated any static resources that it requires for its own use. It is at this point that instances of the device can be created. Whilst it it is possible for the driver to be unloaded in this state, it will only happen when there are drivers in the probed or earlier states.

Opened

This can only be reached from the ready state, but signifies that there are instances of the driver created and in use by either a user program or another driver. In this state the driver will not be unloaded from memory, even under low memory conditions.

The opened state does not consider the number of instances that have been created of this driver.

Removed

When a removable device has been removed, the driver enters the remove state. Note that this does not apply to removable media such as floppy disks, but rather removable devices such as PCMCIA cards and USB devices.

This state is not normally used by many drivers, however it is available for those drivers that may require it.

XXX - Is this state really necessary? Or should it be dealt with somewhere else.