I know that device drivers are attached to device controllers, which have their own registers and some local buffer storage. I'm wondering if I can think of device drivers as little state machines -- i.e. do they read and write to memory, or not?
$\begingroup$
$\endgroup$
2
-
$\begingroup$ Depends, probably? $\endgroup$– RaphaelCommented Mar 11, 2015 at 7:45
-
$\begingroup$ if the memory is finite it can be regarded as a state machine. a simpler driver is better from a quality assurance pov, less likely to have defects & more possible to verify. however most drivers probably are too complex to be modelled as one...? $\endgroup$– vznCommented Mar 11, 2015 at 18:03
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
4
Many device drivers do read/write to memory. For instance, consider a network device; it reads the packets to be sent from memory and writes the packets it receives to memory. Or think of a hard disk driver; it does something analogous. So, ultimately, it will depend on the driver.
That said, device drivers often do have a portion of their internal state that can be thought of a state machine. For instance, the states could be something like UNINITIALIZED, ACTIVE, SUSPENDED, where it is initially in UNINITIALIZED state on boot; after it initializes the device registers, it could transition to ACTIVE state; on suspend, it might put the device into suspend mode and switch to the SUSPENDED state, and so on. This only accounts for part of the behavior of the device driver, but it can still be a helpful way to organize the driver. Or, in other words: often, some important aspects of the driver's behavior or state can be thought of as DFAs even though that's only approximately true.
-
$\begingroup$ Okay, so it seems like you're saying that drivers often can be thought of as DFAs even though that's only approximately true. Is that accurate? $\endgroup$– Eli RoseCommented Mar 11, 2015 at 22:17
-
$\begingroup$ @EliRose, yes, roughly, thank you for the concise re-statement. Often, some parts of their behavior/state can be thought of DFAs (even though this might be only approximately true). $\endgroup$– D.W. ♦Commented Mar 11, 2015 at 22:18
-
$\begingroup$ @EliRo I don't wish to answer, being too far outside my area of competence. I think a lot of drivers, not just in computers, but also in all types of equipments, including airplanes, are programmed with synchronous parallelism techniques. My limited recollection is that you have a finite state backbone, driving sequential code fragments. This can be programmed with specialized parallel programming languages such as Esterel, Lustre, and others. The compiling technology uses finite state technique at its core, but goes much beyond that mathematically. Maybe someone can develop better than I can. $\endgroup$– babouCommented Mar 11, 2015 at 22:41
-
$\begingroup$ @EliRose As memory comes back, vaguely, I think the finite state aspects relates to the exchange of synchronicity signals, that can be understood as the input tokens of finite state machines (sorry for being very approximative). Hence, D.W.'s answer would be consistent with this idea of having DFAś at the core, with a little bit more around it (the sequential code). $\endgroup$– babouCommented Mar 11, 2015 at 22:46
$\begingroup$
$\endgroup$
In software engineering, the "state machine" is more of a design tool than anything else. But yes, many device drivers are designed as state machines. This is because many hardware devices, or the protocols by which you speak to them, have distinct states.
Take the SCSI command protocol as an example. You can do SCSI over many devices (parallel, serial, USB, fibre, etc). However, the idea is the same: Send a command, wait for a response, send another command, wait for another response, and so on.
So we have two logical "states":
State 1: The driver is not waiting for a response from the device.
State 2: The driver is waiting for a response from the device.
There are also two kinds of "event":
Event 1: The operating system asks for some operation to be performed.
Event 2: The device sends a response.
In state 1, event 1 causes the driver to issue a command, and enter state 2. If event 2 happens, then something went wrong.
In state 2, event 1 might cause the driver to buffer the operation (say). Event 2 causes the driver to issue a response to the operating system, and then see if any operations are buffered. If so, issue a new command. If not, enter state 1.
This is a fairly simple device, and already we have something that looks pretty much like a state machine. Moreover, this device is fairly "smart", and doesn't require very much intelligence on the part of the driver. A dumber device, such as a floppy drive (which requires low-level commands like "raise the read/write head" and "move the read/write head 5 tracks that way") might require a lot of states simply because of all the moving parts that it's the responsibility of the driver to keep track of.
In general, a driver needs to keep track of the state of the device, and so state machines are often a very good way to design them.
answered Mar 12, 2015 at 0:16