Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #2917 > unrolled thread
| Started by | hayato.fujimoto@yahoo.com |
|---|---|
| First post | 2013-01-26 08:49 -0800 |
| Last post | 2013-01-29 19:24 +0000 |
| Articles | 2 — 2 participants |
Back to article view | Back to comp.programming
15 years SwDev experience, still an idiot (aka How device drivers really work) hayato.fujimoto@yahoo.com - 2013-01-26 08:49 -0800
Re: 15 years SwDev experience, still an idiot (aka How device drivers really work) jt@toerring.de (Jens Thoms Toerring) - 2013-01-29 19:24 +0000
| From | hayato.fujimoto@yahoo.com |
|---|---|
| Date | 2013-01-26 08:49 -0800 |
| Subject | 15 years SwDev experience, still an idiot (aka How device drivers really work) |
| Message-ID | <5573e4cc-893d-495f-a204-0253d279ac72@googlegroups.com> |
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
[toc] | [next] | [standalone]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Date | 2013-01-29 19:24 +0000 |
| Message-ID | <amqlv1F2p8pU1@mid.uni-berlin.de> |
| In reply to | #2917 |
hayato.fujimoto@yahoo.com wrote:
> 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.
Were did you got that impression from? I haven't dealt with drivers
for storage devices, but a number of dat acquisition cards and there
you (i.e. your driver) definitely fiddle with the "native functio-
nality" - otherwise there typically never would be any data that
the CPU then could play with. You have to set up the card to start
doing AD conversion, at what rate, into wich buffer, what might
trigger the AD conversion etc. The kernel doesn't know how to do
that and only your driver does.
On the one hand your driver may have to get data to or
from the device that make the device look like a file (if
that's possible and reasoable), so read(), write() and pos-
sibly poll() and select() can be used. Of course, for that
you also need something that is invoked for the open() and
close() call for the device file. And beside that file
I/O interface you set things so that the functionality can
be controlled via ioctl() calls (at least under Linux and,
as far as I know, also under other UNIX flavors - I have
no experience with Windows in this respect).
(Note that file I/O stuff isn't mandatory, i.e. you can
also organize the data transfer to happen via ioctl()
calls, but it's typically a good idea to have it if
possible. What you definitel need is something for the
open() and close() functionality.)
Then someone in userland can control the device using calls
of ioctl() with the device file, some constant you defined
and some further arguments suitable for the functionality
for what the call is supposed to achieve. You have a cer-
tain constant to get the card to start converting, one for
stopping it, one for setting the conversion rate etc.
The "normal user" usually doesn't know about these ioctl
calls because the driver most of the time comes with a
library, that has functions named like start_conversion(),
stop_conversion(), set_rate() etc., which wrap those ioctl
calls that might be a bit too arcane for someone who just
wants his device to work and not understand how things are
dealt with on a level nearer to the bare metal. (And that
library often also imposes some policy on how the device
can be used while this should be avoided in the driver.)
Your experience with the SCSI-USB adapter might be a bit of
a red hering since a lot of the needed functionality both
for dealing with SCSI as well as USB devices is already in
the kernel, so all you may need to do in that case is to
write some "glue" code that connects the ends. But in
other drivers you definitely have to take care of all the
functionality of the device by writing or reading to cer-
tain hardware registers of the device.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
[toc] | [prev] | [standalone]
Back to top | Article view | comp.programming
csiph-web