<div dir="ltr"><div><div><div><div><div><div><div>I think the webpage itself will talk what are the drivers that are preferred in the user space. <br><br></div>In principle, following are the broad constituents of any device driver. <br>
</div>1. code operating on device registers / device memory / device FIFO (through device registers)<br></div>2. code operating on some data in the system memory. <br><br></div>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). <br>
<br></div>With the help of <b>mmap()</b> system call and with the help of <b>remap_pfn_range()</b> 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. <br>
<br></div><div>Also the user code can allocate memory in the system memory and access it. <br></div><div><br></div>But the main point of debate/concern is how the data is sent or received to/from the device. <br><br></div>
<div>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). <br>
</div><div>This can be done both by the code at the user space as well at the kernel space easily.<br></div><div><br></div><div>Receiving data from the device has two mechanisms. <br></div><div>* Device can be polled for data or<br>
</div><div>* Driver code can wait for the data from the device ( normally happens through interrupt mechanism)<br><br></div><div>If the device is polled for data then it can happen either from the user space or kernel space. <br>
<br></div><div>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 <b>efficient </b>mechanism till now for the control to be transferred to the waiting user space code on the reception of the interrupt. <br>
<br></div><div>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. <br><br></div><div>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. <br>
<br></div><div class="gmail_extra">-- <br>Regards,<br>Prabhunath G<br>Linux Trainer<br>Bangalore<br><br><br><div class="gmail_quote">On Tue, May 14, 2013 at 1:22 AM, Gergely Buday <span dir="ltr"><<a href="mailto:gbuday@gmail.com" target="_blank">gbuday@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi there,<br>
<br>
I learned, e.g. from here that user space device drivers are indeed possible:<br>
<br>
<a href="http://www.makelinux.net/ldd3/chp-2-sect-9" target="_blank">http://www.makelinux.net/ldd3/chp-2-sect-9</a><br>
<br>
Are there serious user space drivers in Linux? Could you name a few?<br>
<br>
Or, is this just for hacking a driver for your home-made hardware?<br>
<br>
- Gergely<br>
<br></blockquote></div><br><br>
</div></div>