Re: When to write as a device driver instead of just a library.
From: Kasper Dupont (kasperd_at_daimi.au.dk)
Date: 01/13/05
- Next message: David Schwartz: "Re: Multithread synchronization with read and write funcs."
- Previous message: avsrk_at_mailcity.com: "When to write as a device driver instead of just a library."
- In reply to: avsrk_at_mailcity.com: "When to write as a device driver instead of just a library."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 13 Jan 2005 16:28:06 +0100
avsrk@mailcity.com wrote:
>
> Hello Folks ,
>
> I am a little new to device driver development , i am very used to
> development at internals / ipc's etc . I was wondering , when would
> one write the code as a device driver as opposed to a plain simple
> library .
In general if it can be done in user mode, it should be done
in user mode. Whether the user mode code should be library or
a complete program is a different matter. Of course this is
not a definite answer to your question, it is more a rule of
thumb. If there are major drawbacks to a user mode implementation
or major advantages to a kernel mode implementation, it should
be done in kernel mode even if a user mode implementation is
possible. But always try to keep the kernel code as simple as
possible. Complicated kernel code is errorprone and should be
considered a disadvantage.
>
> For example let us take a digital camera , the code for talking to ot
> over USB and capturing the pictures into a computer , should we write
> the code talking to the camera as a seperate library as opposed to
> device driver . I think the computer (x86) comes with the general USB
> drivers (i.e a way to talk to the port i.e protocol ) and the device
> specific (here digital camera) could just get into a user space library
> . Is that true should it be device driver in the kernel mode . What
> are the factors which determine if it should be just device driver or
> just a user space library . If both are an option what are the
> advantages / disadvantages of one over the other .
I don't know a lot about USB programming. So what I'm going to
say now is more relevant to parallel/serial ports, then I hope
you can figure out how much of it applies to USB as well.
There is a serial driver in the kernel, which user mode programs
can use. If you communicate with a device that way, the kernel
doesn't know anything about the actual protocol you are using
over the serial link. That may be good approach for a lot of
serial devices, but if multiple programs try to use the port at
the same time they will either have to wait or risk messing
with each other's communication. A serial terminal works fine
in spite of this, other units may also work fine. But if you
want to connect a modem and run ppp, you will use the ppp driver
present in the kernel. That is because networking is implemented
in the kernel, and network drivers like ppp needs to be there as
well. Most networking could be implemented using a user mode
program and the tun/tap driver, but for communicating with
physical hardware that would be an awkward and inefficient design.
Now let's consider digital cammeras. If you want to use a single
program for transfering images, a user mode implementation would
at first seem like a good idea. Some older models could be
connected to a serial port, most newer models can be connected to
a USB port. There is one significant difference. On a serial
port there will usually be only one device, while the USB port
is designed to handle a large number of devices. Access control
to these devices is something you want to handle in the kernel.
First of all different programs may want to access different
devices at the same time, and you might want to use the
permission system to decide which user is allowed to communicate
with which device. Assume you have a printer, a mouse, an ethernet
adapter, and a digital cammera connected to your USB port. You
want LPD to communicate with the printer, X to communicate with
the mouse, and the kernel itself to communicate with the ethernet
adapter. And then you may want a program to be able to communicate
with the cammera. You may decide that the logged in user should
be allowed to communicate directly with the cammera, but you will
not allow him to communicate with the other units. To achieve this
the kernel must implement at least part of the USB system, since
it must be able to decide which program communicates with which
device. OTOH it isn't strictly necesarry for the kernel to know
the protocols used for printer, mouse, and cammera.
But you may still want to move more code into the kernel. A typical
2.6 system does more of the mouse handling in kernel than a 2.4
system. You may have multiple pointing devices, and both gpm and
two different X servers needs to receive input from all of them
depending on which VC is active. To make this work the kernel
needs to have some understanding of the mouse protocol.
For a cammera you might not be satisfied with just having a program
to transfer files. There usually is a FAT file system on the
storage media in the cammera. You may want to mount this file
system. To achieve that the kernel must communicate with the
cammera, there exist a block device driver for this purpose. When
you combine the vfat driver and the usb-storage driver, you can
mount a digital cammera as a file system.
At least I hope this gives you some hints about the reasons for
sometimes chosing a user mode implementation and other times a
kernel mode implementation. Drivers exists to allow user mode
implementations of a lot of devices, at least network devices
and block devices can be implemented in user mode with a standard
kernel. Using third party modules also file systems can be
implemented mostly in user mode. At least for stability reasons
it may be a good idea to use this for your first implementation,
when you know exactly what you want to do, you may then decide
that a kernel implementation is the way to go.
-- Kasper Dupont
- Next message: David Schwartz: "Re: Multithread synchronization with read and write funcs."
- Previous message: avsrk_at_mailcity.com: "When to write as a device driver instead of just a library."
- In reply to: avsrk_at_mailcity.com: "When to write as a device driver instead of just a library."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
