user space device drivers

user space device drivers

[Gergely Buday]

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

user space device drivers

[Sannu K]

> Are there serious user space drivers in Linux? Could you name a few?

Printer drivers, scanner drivers, file system drivers etc.

Hope this helps,
Sannu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130514/4ade81c4/attachment.html 

user space device drivers

[Gergely Buday]

>> Are there serious user space drivers in Linux? Could you name a few?
>
> Printer drivers, scanner drivers, file system drivers etc.

How can I find them? Are they in the kernel source tree?

- Gergely

user space device drivers

[richard -rw- weinberger]

On Mon, May 13, 2013 at 9:52 PM, Gergely Buday <gbuday@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?

UIO has lots of serious users.
One prominent VFIO user is qemu/kvm.

--
Thanks,
//richard

user space device drivers

[Prabhu nath]

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@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 

user space device drivers

[Gergely Buday]

Prabhu nath wrote:

> 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.

What are the curently available mechanisms for an interrupt to
propagate into user space?

Is there one that affects the scheduler?

- Gergely

user space device drivers

[Prabhu nath]

One that I know is through proc interface where the interrupt info is
lodged in a file in /proc  and the user code keeps polling on this file.
Exact use of this is to be looked for.




On Tue, May 14, 2013 at 3:24 PM, Gergely Buday <gbuday@gmail.com> wrote:

> Prabhu nath wrote:
>
> > 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.
>
> What are the curently available mechanisms for an interrupt to
> propagate into user space?
>
> Is there one that affects the scheduler?
>
> - Gergely
>



-- 
Regards,
Prabhunath G
Linux Trainer
Bangalore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130514/227eb538/attachment-0001.html 

user space device drivers

[Pietro Paolini]

On May 13, 2013, at 9:52 PM, Gergely Buday <gbuday@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
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Some are suggested in the ldd3 link, for example SANE (scsi scanner devices).

http://www.sane-project.org/source.html

You can find sources there.

 - Pietro

user space device drivers

[richard -rw- weinberger]

On Tue, May 14, 2013 at 11:54 AM, Gergely Buday <gbuday@gmail.com> wrote:
> Prabhu nath wrote:
>
>> 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.
>
> What are the curently available mechanisms for an interrupt to
> propagate into user space?

See VFIO and UIO.
Even the gpio sysfs interface allows you to catch interrupts.

> Is there one that affects the scheduler?

???

--
Thanks,
//richard

Re: user space device drivers

[jeshkumar555]

Hi :),

One more mechanism I know is passing real time signal to the userspace process using process PID. So whenever there is an interrupt in kernel module, it passes the signal to userspace process. You can handle the signal in US process.

And I passed the PID to kernel module using IOCTL. 

Let me know if anyone finds problem in handling interrupts like this.

Thanks


Regards,
Jeshwanth
Bengaluru

----- Reply message -----
From: "Prabhu nath" <gprabhunath@gmail.com>
Date: Tue, May 14, 2013 3:29 pm
Subject: user space device drivers
To: "Gergely Buday" <gbuday@gmail.com>
Cc: "kernelnewbies" <kernelnewbies@kernelnewbies.org>


One that I know is through proc interface where the interrupt info is
lodged in a file in /proc  and the user code keeps polling on this file.
Exact use of this is to be looked for.




On Tue, May 14, 2013 at 3:24 PM, Gergely Buday <gbuday@gmail.com> wrote:

> Prabhu nath wrote:
>
> > 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.
>
> What are the curently available mechanisms for an interrupt to
> propagate into user space?
>
> Is there one that affects the scheduler?
>
> - Gergely
>



-- 
Regards,
Prabhunath G
Linux Trainer
Bangalore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130514/23e69e18/attachment.html 

user space device drivers

[richard -rw- weinberger]

On Tue, May 14, 2013 at 10:18 AM, Gergely Buday <gbuday@gmail.com> wrote:
>>> Are there serious user space drivers in Linux? Could you name a few?
>>
>> Printer drivers, scanner drivers, file system drivers etc.
>
> How can I find them? Are they in the kernel source tree?

They are everywhere except the kernel source.

--
Thanks,
//richard

user space device drivers

[Greg Freemyer]

On Tue, May 14, 2013 at 4:18 AM, Gergely Buday <gbuday@gmail.com> wrote:
>>> Are there serious user space drivers in Linux? Could you name a few?
>>
>> Printer drivers, scanner drivers, file system drivers etc.
>
> How can I find them? Are they in the kernel source tree?
>

Filesystem drivers would use FUSE.

A fairly long list of those is in the examples section of:

http://en.wikipedia.org/wiki/Filesystem_in_Userspace

Not all of those are Linux FUSE based, so don't assume they are all
Linux filesystems, but many of them are.

Note that a lot of filesystems that originate outside of linux, first
come to linux as FUSE implementations.  They may later be ported to
native kernel modules.  It is a effort vs. reward trade-off.  I
suspect the best known linux FUSE based filesystem is NTFS-3G.  I've
done some performance testing of it based on large files and USB3
connectivity.  I don't see any meaningful performance degradation
compared to EXT4 under the same restrictions.

Greg