Message-Id: <200704280228.47500.hjk@linutronix.de>
Date:	Sat, 28 Apr 2007 02:28:46 +0200
From:	Hans-Jürgen Koch <hjk@...utronix.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Greg KH <gregkh@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	Benedikt Spranger <b.spranger@...utronix.de>
Subject: Re: [GIT PATCH] UIO patches for 2.6.21

Am Samstag 28 April 2007 01:04 schrieb Andrew Morton:
> On Fri, 27 Apr 2007 15:49:57 -0700
>
> Greg KH <gregkh@...e.de> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists