Re: [GIT PATCH] UIO patches for 2.6.21

On Fri, Apr 27, 2007 at 04:04:25PM -0700, Andrew Morton wrote:
On Fri, 27 Apr 2007 15:49:57 -0700
Greg KH <gregkh@xxxxxxx> 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.

It's not a closed vs. open issue, it just turns out that a lot of people
keep trying to write PCI drivers in userspace (how many different papers
were published on this topic alone in the past year...). This framework
is to allow this to happen in a sane and correct way.

Lots of different types of odd devices do not fit into the "kernelspace
driver" framework very well for a variety of reasons:
- zillions of different controls in the card
- floating point is needed to compute the next step of an
operation in moving a physical object

With this framework, we provide a solid and simple way to provide for
these kinds of devices. The Linutronix guys have had a lot of
experience in supporting this kind of hardware in the past and can
provide better examples if you need.

But yes, it does allow you to write a PCI driver in userspace, being
closed source, if you really want to. But if you do that, then you get
_no_ advantages of being in the kernel (caching, common userspace
interface, resource management, etc.) and need to handle that all
yourself. Heck, that's pretty much what X does today for lots of old
video cards :)

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?

No, you still need kernel code to handle the interrupt properly, we do
not want userspace to do this as it would slow the system down and do
all sorts of other bad things. That's the main problem with all of
those other proposals that people have for trying to do this kind of
work in the past (can't share irqs, can't block on userspace in an
interrupt handler, etc.)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH] [PNP] modalias sysfs export
    ... let the device table match one of these id's in that single string: ... If that driver is unavailable, ... userspace exclusively. ... that created by the kernel. ...
    (Linux-Kernel)
  • Re: Frameworks [WAS: Cost of developing a device driver]
    ... in the kernel, there were issues with the DW drivers I developed that I ... >> Just because Windows kernel development is stuck in the stone age doesn't ... > actually love to see a good framework for Windows kernel development (I ... > developers take existing code for a driver and turn it into a new driver. ...
    (microsoft.public.development.device.drivers)
  • Re: [GIT PATCH] UIO patches for 2.6.21
    ... GPL'ed kernel rather than encouraging them to do closed-source userspace ... driver, which are just there to flip some bit in the chip registers is ...
    (Linux-Kernel)
  • Re: [RFC][PATCH 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
    ... >> the kernel tree. ... > is doing with the open source dcdbas driver and all of the other SMI ... SMI from userspace can be tricky, ... Reading/writing the values behind the CMOS/SMI tokens (BIOS F2 ...
    (Linux-Kernel)
  • Re: [RFC] Simple userspace interface for PCI drivers
    ... in userspace in a sane manner. ... What about portable access to the PCI DMA API from userspace? ... are implemented as platform devices in kernel space). ... the kernel to claim a device or register an iio driver. ...
    (Linux-Kernel)