Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #2921

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

Show all headers | View raw

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

Back to comp.programming | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

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

csiph-web