Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

15 years SwDev experience, still an idiot (aka How device drivers really work)

6 views
Skip to first unread message

hayato....@yahoo.com

unread,
Jan 26, 2013, 11:54:46 AM1/26/13
to
Hello,

There are three reasons for this post.
1) Over the past few days I have realized what an idiot I have been when it comes to device drivers, even though I have 15 years of work experience (although in application software area)
2) I have read up on device drivers. I think I understand now how they work, but I want to verify my understanding
3) I am appalled that many of my more experienced colleagues have similar misconceptions when it came to device drivers

Let us start with the first reason. All these years, while working on application software, I maintained a safe distance from device drivers, although I kept reading descriptions like " In computing, a device driver is a computer program that operates or controls a particular type of device that is attached to a computer." (Wikipedia). Now that I have delved deeper, I know how misleading this description is. This description, and other descriptions like this, can give a false impression that a device driver can control the native functionality of a peripheral. For example, I thought that the driver for a SCSI-USB adapter contained the logic for interworking between SCSI and USB. Now that I have read this stuff up, I could not have been more wrong!

It appears to me (and that brings me to my second reason), that THE JOB OF A DEVICE DRIVER IS TO CONTROL ACCESS TO A PERIPHERAL (over the data and control buses) AND NOT TO CONTROL THE NATIVE FUNCTIONALITY OF THE PERIPHERAL. In other words, the device driver only controls how data is exchanged between the CPU and the peripheral device but not the native functionality of the device. Even after a device driver is installed, the peripheral device remains largely a black box for the CPU. In the absence of a suitable device driver, it is as if the CPU is saying "I know that there is a device of type X out there, but I don't know how to communicate with the device" i.e. device does not know how to request data from or send data to a device. This is an important role, no doubt, but frankly I am shocked that the device driver does not play a more significant role. I am not saying that it should, but frankly that I what I thought all along.

Based on what I have read, the role of the device driver seems to be:
1) Register/deregister the driver in the kernel space
2) Describe whether the peripheral is a RO, WO or RW device
3) Describe which native I/O routines supported by the CPU need to be invoked (e.g. blocking vs non-blocking I/O routines) in order to communicate with the device
4) Bind the device to the correct bus
5) Establish identity for the device to avoid conflict and confusion with other peripherals that are connected via a similar hardware interface (e.g. USB device A vs USB device B)
5) Transfer data between user and kernel space
6) Specify what kind of initialization/cleanup is needed:
i) when a device is plugged in (or first detected)
ii) when a device is plugged out
iii) before a read operation
iv) before a write operation
v) after a read operation
vi) after a write operation
7) Manage any state model associated with the data exchange between the CPU and the peripheral device

Based upon my understanding, I have come up with the following ASCII art layering for device drivers. I would like the experts to judge whether or not after 15 long years I have finally understood this stuff. Kindly view in a fixed font.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ SOFTWARE ~
~ ======== ~
~ ------------------- ~
~ | Application | ~
~ ------------------- ~
~ | ~
~ | ~
~ v ~
~ ------------------- ~
~ | Device Driver | ~
~ ------------------- ~
~ | | | ~
~ -------------------------- | | ~
~ | | | ~
~ v v | ~
~ ------------------ -------------------- | ~
~ | Kernel module | | Hardware interface | | ~
~ | initialization & | | specific kernel | | ~
~ | cleanup routines | | routines | | ~
~ ------------------ -------------------- | ~
~ | | | ~
~ | | | ~
~ | v v ~
~ | ---------------------------- ~
~ | | Common kernel I/O routines | ~
~ | ---------------------------- ~
~ | | ~
~ | | ~
~ | | ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ HARDWARE | | ~
~ ======== | | ~
~ (via the bus) | | (via the bus) ~
~ v v ~
~ -------------------- ~
~ | Hardware interface | ~
~ | controller | ~
~ -------------------- ~
~ | ~
~ | (hardware interface ~
~ | specific protocol) ~
~ v ~
~ ---------------- ~
~ | Peripheral | ~
~ ---------------- ~
~ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Some references:
1) http://lwn.net/Kernel/LDD3/
2) http://www.linuxforu.com/2011/12/data-transfers-to-from-usb-devices/

Regards,
Hayato
0 new messages