user space device drivers

Prabhu nath gprabhunath at gmail.com
Tue May 14 05:46:20 EDT 2013


I think the webpage itself will talk what are the drivers that are
preferred in the user space.

In principle, following are the broad constituents of any device driver.
1. code operating on device registers / device memory / device FIFO
(through device registers)
2. code operating on some data in the system memory.

The main reason why drivers are preferred in the kernel space is
accessibility of device registers/memory i.e. the device registers/memory
can be mapped to the kernel virtual address space (the vmalloc region).

With the help of *mmap()* system call and with the help of *
remap_pfn_range()* kernel function the device registers/memory can be
mapped to the user virtual address space and thus we can make the driver
code in the user space access the device registers/memory.

Also the user code can allocate memory in the system memory and access it.

But the main point of debate/concern is how the data is sent or received
to/from the device.

Sending data to the device will happen at the trigger of the application.
Thus when ever an application intends to send data to the device, the
device driver code can write to the device memory or device FIFO (through
device registers) mapped to the virtual address space (either user virtual
address or kernel virtual address).
This can be done both by the code at the user space as well at the kernel
space easily.

Receiving data from the device has two mechanisms.
* Device can be polled for data or
* Driver code can wait for the data from the device ( normally happens
through interrupt mechanism)

If the device is polled for data then it can happen either from the user
space or kernel space.

But if the device has to generate an interrupt on the reception of the data
then it is best for the driver code to be in the kernel space waiting for
the data, rather than in the user space because there is no *efficient
*mechanism
till now for the control to be transferred to the waiting user space code
on the reception of the interrupt.

Thus to conclude, drivers are preferred to be placed in the kernel space
for the devices whose data have to be received through interrupt mechanism.

Hence we see drivers' for most of the output devices (E.g. display device )
are preferred to be in the user space and for most of the input devices
(E.g. mouse, keyboard) and network devices (E.g. Ethernet card) are
preferred to be in the kernel space.

-- 
Regards,
Prabhunath G
Linux Trainer
Bangalore


On Tue, May 14, 2013 at 1:22 AM, Gergely Buday <gbuday at gmail.com> wrote:

> Hi there,
>
> I learned, e.g. from here that user space device drivers are indeed
> possible:
>
> http://www.makelinux.net/ldd3/chp-2-sect-9
>
> Are there serious user space drivers in Linux? Could you name a few?
>
> Or, is this just for hacking a driver for your home-made hardware?
>
> - Gergely
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130514/62a5df04/attachment-0001.html 


More information about the Kernelnewbies mailing list