Am Samstag 28 April 2007 01:04 schrieb Andrew Morton: > On Fri, 27 Apr 2007 15:49:57 -0700 > > Greg KH <[EMAIL PROTECTED]> wrote: > > Here are the updated UIO (Userspace I/O driver framework) patches for > > 2.6.21. > > 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. > > But I don't think I have the capacity to actually think about this further > - just tossing it out there ;)
Thanks for tossing it out ;-) I understand your uncertainty and I share your opinion about encouraging industry developers to GPL their drivers. It really took me some time until I understood that sometimes there are _good_ reasons for a closed driver. UIO is not intended for mass products like graphic cards. We're talking about companies who developed special hardware for use in special applications like machine control. They sometimes need to keep a part of their driver closed, at least for some time. Sometimes it's because they want to protect themselves, sometimes because their customer demands it. Usually, they know about the disadvantages you mentioned (if they're our customers, be sure we tell them!). Anyway, UIO is not just a system to allow closed drivers. There are enough other reasons why these industry developers want userspace drivers. The most important one is that they're usually no experienced kernel developers. They can let somebody write the kernel part for them, and then write their driver using the tools and libraries they know, with floating point and all that stuff. It's just convenient. If I had to write a driver for a fieldbus card today, I'd use UIO. And I'd make it free software. UIO doesn't force anybody to close his drivers. > > > They have been revamped from the last time you have seen them, and they > > include a real driver, the Hilscher CIF DeviceNet and Profibus card > > controller, which is being used in production systems with this driver > > framework right now. The kernel driver they replaced was a total mess, > > with over 60+ ioctls to try to control the different aspects of the > > device. See the last patch in this series for more details on this > > driver. > > > > These patches include full documentation, are self-contained from the > > rest of the kernel, and have been in the -mm tree for the past few > > months with no complaints. > > > > Please pull from: > > master.kernel.org:/pub/scm/linux/kernel/git/gregkh/uio-2.6.git/ > > > > Patches will be sent as a follow-on to this message to lkml for people > > to see. > > > > drivers/uio/uio_cif.c | 156 ++++++++ > > eh? How come a particular device requires 156 lines of kernel code to > support a userspace driver? Doesn't that kind of defeat the point? This is quite a large kernel module for an UIO device due to quite stupid hardware design. It needs two memory mappings, and the interrupt handler is not the simplest thing possible. BTW, I don't think that 156 lines is so much. It allows to handle quite a complex PCI card. And it's so simple that it can be even explained to industry programmers who are no kernel gurus. Thanks, Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
