[Posted May 2, 2007 by corbet]

The concept of supporting user-space drivers has appeared on this page a few times before. It's back; this time there is a version of the patch (now called "UIO") which is being proposed for inclusion into 2.6.22. The interface has changed somewhat, so another look is called for.

Like the previous version, UIO does not completely eliminate the need for kernel-space code. A small module is required to set up the device, perhaps interface to the PCI bus, and register an interrupt handler. The last function (interrupt handling) is particularly important; much can be done in user space, but there needs to be an in-kernel interrupt handler which knows how to tell the device to stop crying for attention.

The kernel module includes <linux/uio_driver.h>. If it's a driver for a PCI device, it should register itself as a PCI driver in the usual way. When it comes time to connect a device (perhaps in the PCI probe()uio_info structure: function), the driver fills in a

    struct uio_info {
	char			*name;
	char			*version;
	struct uio_mem		mem[MAX_UIO_MAPS];
	long			irq;
	unsigned long		irq_flags;
	void			*priv;
	irqreturn_t (*handler)(int irq, struct uio_info *dev_info);
	int (*mmap)(struct uio_info *info, struct vm_area_struct *vma);
	int (*open)(struct uio_info *info, struct inode *inode);
	int (*release)(struct uio_info *info, struct inode *inode);
	/* Internal stuff omitted */
    };

Here, name is the name of the device and version is the driver version (which will show up in sysfs). The number of the interrupt used by the device (if any) goes into irq, with irq_flags being the flags which will be passed to request_irq(). The function which handles interrupts is handler(). This handler should acknowledge the interrupt; it usually does not need to do anything else. The mmap(), open(), and release() functions are called from the equivalent file_operations members.

The mem array describes any memory areas which can be mapped into user space. The uio_mem structure looks like:

    struct uio_mem {
	unsigned long addr;
	unsigned long size;
	int memtype;
	void __iomem *internal_addr;
	/* ... */
    };

For each mappable area, addr is the relevant address, and size is the size of the area. If it's an I/O memory area, internal_addr is the address returned by ioremap(). The memtype field describes what the area really is:

UIO_MEM_PHYS indicates that addr is a physical address, generally for an I/O memory area.
UIO_MEM_LOGICAL is memory in the kernel logical address space, such as that returned by kmalloc().
UIO_MEM_VIRTUAL is memory in the kernel virtual address space - the space used by vmalloc_user() and friends.

Once the structure is filled in, the driver stub passes it to:

    int uio_register_device(struct device *parent, struct uio_info *info);

The parent pointer tells the kernel which "real" device is associated with the UIO device; if the driver is for a PCI device, parent will be pci_dev->dev.

There is not much more to the kernel-space UIO API. When a device goes away, the driver should call:

    void uio_unregister_device(struct uio_info *info);

The final function of note is:

    void uio_event_notify(struct uio_info *info);

Its purpose is to notify the UIO core that an event (typically an interrupt) has occurred. The stub driver need not call uio_event_notify() for real interrupts, but it can be used to simulate interrupts in other situations.

On the user space side, the first UIO-handled device will show up as /dev/uio0 (assuming a normal udev setup). The user-space driver will open the device. Reading the device returns an int value which is the event count (number of interrupts) seen by the device; if no interrupts have come in since the last read, the operation will block until an interrupt happens (though non-blocking operation is supported in the usual way as well). The file descriptor can be passed to poll().

The memory areas described by the kernel-space driver can be mapped into user space with the mmap() call. The interface is just a little strange: the offset value passed to mmap() should be N times the page size for the Nth memory area. So, on a system with 4096-byte pages, the first memory area will be found with an offset of zero, the second at 4096, the third at 8192, etc. Once that is figured out, though, everything is pretty straightforward.

There are some limitations, of course. UIO drivers are char drivers; there is no provision for creating user-space block or network drivers at this time. It is not possible to set up DMA operations from user space. But, for drivers which can be implemented with I/O memory access and simple interrupt handlers, the necessary pieces are in place. The patch set includes an example driver to show how it all works. According to Thomas Gleixner, the original, fully in-kernel version of the driver had to implement 68 different ioctl() commands and was over 5,000 lines long. The associated user-space code was over 3,000 lines as well. The new driver eliminates all of that, with a total of 156 lines of kernel code and just under 3,000 lines in user space.

Andrew Morton has expressed some reservations about the patch:

I'm a bit uncertain about the whole UIO idea, really. I have this vague feeling that we'd prefer to encourage people to move device drivers into GPL'ed kernel rather than encouraging them to do closed-source userspace implementations which will probably end up being slower, less reliable and unavailable on various architectures, distros, etc

The authors respond that it's not really about doing proprietary drivers, though some of that will undoubtedly go on. There's a number of people, especially in the embedded space, who want to do user-space drivers, for prototyping purposes if nothing else. The UIO framework gives them a relatively safe and standard way to write these drivers, which is seen as being better than having them each create their own kernel hooks. The patch has not been merged as of this writing, but, unless stronger objections arise, it's chances of getting into 2.6.22 are reasonably good.

(Log in to post comments)

UIO: user-space drivers

Posted May 3, 2007 20:06 UTC (Thu) by xav (subscriber, #18536) [Link]

People in the embedded space don't do prototypes. They hack something until it works, then it's done.

UIO: user-space drivers

Posted May 4, 2007 14:43 UTC (Fri) by nlucas (subscriber, #33793) [Link]

I'm with you. It sounds more like an excuse than a real reason.

This dangerously seems like an atempt to be able to create proprietary drivers and bypass the GPL.

On one hand I understand the good of having user-space drivers, but on the the other hand I don't see how that can be done and not create this loophole.

UIO: user-space drivers

Posted May 4, 2007 16:11 UTC (Fri) by zlynx (subscriber, #2285) [Link]

So what if people do use it to bypass the GPL? Developers were doing user-space drivers *anyway*. And doing it badly in most cases.

It depends on if your goal is to write an excellent, open OS kernel or to force all software in the world to become GPL.

UIO: user-space drivers

Posted May 4, 2007 17:19 UTC (Fri) by nlucas (subscriber, #33793) [Link]

The kind of user-space drivers people were doing don't compare with the drivers you will be able to do, even if you probably can't do a user-space graphics driver.

Also note that I'm not a GPL zealot, but I agree with the "doomsday scenario for linux in a binary world" (OTOH I don't buy the "stable API nonsense").

Other than that, I don't have problems running the nvidia drivers at my home PC (the few games I still play need 3D).

UIO: user-space drivers

Posted Oct 19, 2007 3:22 UTC (Fri) by ofranja (guest, #11084) [Link]

Companies which do not want their work to become GPL'ed just need to make 
a tiny little "wrapper" driver inside the kernel, and then implement 
everything that matters in the userspace. In some (not to say many) 
scenarios, this approach actually is much better and saner than 
implementing everything in the kernel driver. 
 
BTW, one thing "home Linux users" should remember is that Linux is not 
strong in the home PCs as it is strong in the server market. Many 
companies in that scenario do not care about openess of some driver, as 
long as it works and/or you (the seller) fix it in case it breaks. 
Sometimes they prefer not having the source code and buy from someone who 
is more expensive, because the solution is better and more complete. 
 
IMHO, keeping this UIO infrastructure out of the kernel fearing a "binary 
takeover" would be like keeping FUSE out of the kernel fearing 
"proprietary filesystems" from taking over Linux: something we should not 
be afraid of. 
 
And that's it.

UIO: user-space drivers

Posted Jun 5, 2007 10:15 UTC (Tue) by hjkoch (subscriber, #45353) [Link]

As one of the main authors of UIO I can tell you that license issues were
never an important topic in our discussions. Our judge and jury is Greg
Kroah-Hartman, who is certainly not in favor of proprietary drivers. Our
target audience are programmers in industry, who have to write a driver
for an exotic card that could never make it into mainline. They're neither
kernel experts nor do they write good code (they don't have the time).
With UIO, they can let somebody else write the 150 lines of kernel code,
which _has_ to be GPL, and the big part can be done in userspace, with the
same tools and knowledge needed for their application, anyway. Yes, in
userspace it's possible to choose a different license, but that's not
UIO's fault or intention. It's been like this since Linux exists.

UIO: user-space drivers

Posted Jul 29, 2007 21:43 UTC (Sun) by vphirric (subscriber, #32877) [Link]

Hear hear -- and may I also add that there are lots of specialized little hardware widgets that need software control that simply do not present a character- or block- device paradigm. If your widget is some bizzare one-shot FPGA interface or the like, the existence of this kind of infrastructure is huge help. Thanks much!

UIO: user-space drivers

Posted Jun 5, 2007 10:01 UTC (Tue) by hjkoch (subscriber, #45353) [Link]

Yes. And if it's an in-kernel driver, they either violate the GPL and/or
hack up something completely unmaintainable. UIO gives them the
possibility to do the dirty part of the driver in user space, and it can
simply become a part of their application. They can use the tools they
know, and don't have kernel version issues. And they can choose any
license they want for the userspace part. BTW, all userspace drivers I'm
aware of are GPL.

Printer drivers

Posted Jul 23, 2007 5:54 UTC (Mon) by ringerc (guest, #3071) [Link]

Some printer drivers are implemented in userspace and are not GPL.

The Samsung monstrosity recently covered by LWN is one such example. Another is the CUPS filter & backend shipped with the Xerox CentreWare suite, which is a living fossil, complete with dropping its self into random bits of /usr .

This issue concerns me too. On one hand, I'd prefer a closed source driver to no driver much of the time. On the other hand, if it's a bad driver it's not much better than no driver at all, and lacking the ability to fix or debug it because it's just a binary blob would be seriously annoying.

Hopefully this won't lead to a large surge in closed source userspace drivers. Still, if it does, at least they'll have to work harder to bring the machine down.

Printer drivers

Posted Oct 10, 2007 2:36 UTC (Wed) by Richard_J_Neill (subscriber, #23093) [Link]

It should also be easier to reverse-engineer a userspace driver by just watching what it does. What is *really* nasty are binary drivers with a dependency on a specific (usually 3-years obsolete) kernel version.
For example, I bought an expensive ($500) fast 32-bit parallel I/O card 4 years ago, which claimed to have Linux support. This turned out to be "but only on RedHat 7.3 with the default kernel". In the end, we threw out the hardware. Actually, we replaced it with another "Linux-supported" hardware item, called a QuickUSB. This also had only a binary driver, but it used libusb, and we were able to reverse-engineer it to write a GPL-driver. (But it still wasn't good enough in the end).

[linuxkernelnewbies] UIO: user-space drivers [LWN.net]

Reply via email to