Device Drivers: Difference between revisions
 U05730dg [ PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs)mNo edit summary |
U05730dg [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) mNo edit summary |
||
| Line 23: | Line 23: | ||
The device driver is responsible for translating a request such as ‘read block ABC fron disk XYZ’ into a sequence of | The device driver is responsible for translating a request such as ‘read block ABC fron disk XYZ’ into a sequence of | ||
operations which cause the disk’s mechanics to move in particular ways. Notice that in some cases this can take a considerable time, | operations which cause the disk’s mechanics to move in particular ways. Notice that in some cases this can take a considerable time, so the driver may block and unblock repeatedly. For this purpose device drivers are usually frequent users of [[interrupts]] from the [[peripheral devices]]. There may also be several concurrent users of a particular driver – in different stages of | ||
processing or, perhaps, commanding different physical disks – so the code ususally has to be [[Reentrancy|reentrant]]. | processing or, perhaps, commanding different physical disks – so the code ususally has to be [[Reentrancy|reentrant]]. | ||
Latest revision as of 13:43, 6 May 2024
| Depends on | IO |
|---|
A computer needs I/O. Peripheral devices come in many forms.
The ‘electronic’ interfacing of each physical peripheral is handled by a hardware device which presents the data, control, status etc. through a set of software readable registers. However, as might be imagined, there is still a wide variety of different control registers between devices. At one end of the scale there might be a simple ‘on’/‘off’ bit for an LED; towards the other end there might be a USB controller handling a variety of wildly different devices – from memory sticks to webcams – through a single interface (via a hub).
The software which drives peripheral hardware is a device driver and is usually used to simplify the interface and provide a standardised abstracted interface. For example, a user does not want to care if a storage device is a magnetic disk or a DVD or a USB ‘stick’ or … Ideally they should all be treatable in the same way.
Device drivers therefore often support classes of operations, such as block operations and character streams. Note that a file (for example) could be treated as either of these.
The device driver is responsible for translating a request such as ‘read block ABC fron disk XYZ’ into a sequence of operations which cause the disk’s mechanics to move in particular ways. Notice that in some cases this can take a considerable time, so the driver may block and unblock repeatedly. For this purpose device drivers are usually frequent users of interrupts from the peripheral devices. There may also be several concurrent users of a particular driver – in different stages of processing or, perhaps, commanding different physical disks – so the code ususally has to be reentrant.
Device drivers are also typically resposible for setting up the majority of DMA transfers. These are particularly relevant for block operations although a character stream moving from or to a block device will probably incorporate a buffer.
Techniques for communicating with the hardware are outlined in another article.
Position in O.S.
Home computers support numerous and diverse devices: each device is likely to need its own specific driver. The functionality device drivers provide is certainly part of the abstraction of the machine and, therefore, an operating system responsibility but are the drivers implicitly part of the operating system?
In a monolithic kernel drivers are part of the privileged code; this is a simple model but means that the kernel itself can get very large, with code from numerous sources. The microkernel approach relegates device drivers to user privilege, with system calls to get at the hardware when required, although the drivers are still logically part of the O.S.
Authorship
Device drivers are typically supplied by equipment manufacturers and, therefore, installed when devices are added to the computer. They have to be seen as a potential source of bugs (even, potentially, a security problem) within an operating system, which suggests the microkernel approach – keeping most of the code unprivileged – is a more secure option. They are also, potentially, quite numerous … and large, thus could occupy significant memory resource: however an O.S. might have the policy of only installing a particular driver when it is needed, rather than than loading everything it can find at boot-time.
Device drivers are also the most likely part of an O.S. which you may end up contributing to!
| Also refer to: | Operating System Concepts, 10th Edition: Chapter 12, pages 490-525 |
|---|
