1. Introduction

A HIDD is a Hardware Independant Device Driver - a collection of code that provides an interface to hardware that hides as many details of the hardware as practical. Most applications do not need to know all the details of the device they use, they simply want to get on with using the device.

As we are implementing the Operation System we still want to support the existing software that runs on this platform. This means that we need to also provide an interface to the Exec style devices.

With this in mind, the design goals of the HIDD system are:

Hardware Independant Interfaces

The interface that the driver presents should be independant of the underlying hardware. It should provide as much of the functionality of that device as possible.

Compatability with

There is a large amount of software either with source or binary only that uses the style device drivers. We should provide a way of keeping this software working, but without too great a speed/compatability problem.

Interface Reuse

Many interfaces provide common functionality - for example SCSI, IDE and floppy disk drives all provide a way of writing blocks to disk. We should use this to allow code to work on any kinds of these devices simply by changing the device name.

Code reuse

Many device implementations share common facilities that allow them to reuse code. There are a number of ethernet cards available that whilst they may work on PCI, ISA or Zorro busses - they share the same chipset but differ in access methods. We should attempt to provide the ability to use the same driver code. This has benefits in terms of code testing and reliability, and also the reduced number of drivers that need to be written.

Dynamic Properties

Device drivers should be dynamically loadable and unloadable from the system - this helps with systems with low memory, removable hardware and most importantly, works well with the philosophy.

Language Independance

Whilst true language independance is quite difficult, the interface design has been constructed so that it is relatively simple to add calling methods for different languages. To help with this the interfaces shall be described in some kind of interface description language (such as OMG IDL), and this will be processed to generate the required header files, and class glue files. The language used for most drivers will be C.

To implement the code and interface reuse design goal we have implemented our drivers in an object oriented fashion, providing single inheritance but multiple interfaces (similar to the Java language). The inheritance hierarchy allows us to start with a basic driver, and enhance this by adding more levels of device dependance until we come to a driver for a specific device.

To provide a method of dynamic driver functionality the driver objects are arranged in a tree that shows their connection mechanism. For example a PCI based ethernet card is connected to a PCI bus, so the ethernet card driver is a child of the PCI bus. Similar an IDE harddisk is normally connected to an IDE controller - so the disk will be a child of the IDE controller.

This does not mean that the ethernet card driver is a subclass of the bus driver. Only the dynamic behaviour of the drivers is subject to the connection-oriented approach.

There are a few concepts hidden in all the above. Firstly a knowledge of object-oriented programming is assumed for this document, as is a basic understand of device drivers. This manual is not designed to teach either object oriented programming or device driver programming - both of these come only from experience. I hope that this manual will help however - I am learning as I write it.

Throughout this manual a few terms will be used frequently and often interchangably, hopefully for the few times that I miss these in editing I shall try and clarify them here.

The first two are class and device. The device is the physical implementation of the hardware we are controlling, and the class is the code that is controlling that hardware. You normally only have one class for each device, although some devices may provide multiple functions. In that case you would need to provide multiple classes for the different functions.

The second two are object and driver. The object is an instantiated class and this is the driver for the device. There can be a number of drivers for the same device, but they must all control separate devices. There will be one instantiated driver for every class of device that exists in the system.