UIO patches for 2.6.21

(quoted diff) +12 -0

+static int __devinit hilscher_pci_probe(struct pci_dev *dev,
+					const struct pci_device_id *id)
+{
+	struct uio_info *info;
+
+	info = kzalloc(sizeof(struct uio_info), GFP_KERNEL);
+	if (!info)
+		return -ENOMEM;
+
+	if (pci_enable_device(dev))
+		goto out_free;
+

From: Hans J. Koch <[email protected]>

Documentation for the UIO interface

From: Hans J. Koch <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 Documentation/DocBook/kernel-api.tmpl |    4 +
 Documentation/DocBook/uio-howto.tmpl  |  498 +++++++++++++++++++++++++++++++++
 2 files changed, 502 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/DocBook/uio-howto.tmpl

Documentation/DocBook/uio-howto.tmpl new file +0 -0

new file mode 100644
index 0000000..bd2209f

Documentation/DocBook/uio-howto.tmpl new file +7 -0

+store it in <varname>addr</varname>. Use <varname>internal_addr</varname>
+instead to remember such an address.
+</listitem>
+</itemizedlist>
 
+<sect2 id="adding_irq_handler">
+<title>Adding an interrupt handler</title>
+	<para>

Quoted 1 line

+<title>The Userspace I/O HOWTO</title>

Most of this reads well. Thanks.
A few typo corrections are below...

However, it still fails 'make htmldocs' for me. What am I missing? How did it work for you?
My DTD doesn't like to see <varname> inside a <listitem>:

linux-2.6.21-rc7-mm2/Documentation/DocBook/uio-howto.xml:333: element listitem: validity error : Element listitem content does not follow the DTD, expecting (calloutlist | glosslist | itemizedlist | orderedlist | segmentedlist | simplelist | variablelist | caution | important | note | tip | warning | literallayout | programlisting | programlistingco | screen | screenco | screenshot | synopsis | cmdsynopsis | funcsynopsis | classsynopsis | fieldsynopsis | constructorsynopsis | destructorsynopsis | methodsynopsis | formalpara | para | simpara | address | blockquote | graphic | graphicco | mediaobject | mediaobjectco | informalequation | informalexample | informalfigure | informaltable | equation | example | figure | table | msgset | procedure | sidebar | qandaset | anchor | bridgehead | remark | highlights | abstract | authorblurb | epigraph | indexterm | beginpage)+, got (varname CDATA)

so I removed most of the <varname>s and still had errors. Any suggestions?

Review

Quoted 5 lines

<listitem>
+<varname>void *internal_addr</varname>: If you have to access this memory

(quoted diff) +3 -0

+region from within your kernel module, you will want to map it internally by
+using something like <function>ioremap_nocache()</function>. Addresses
+returned by this function can not be mapped to user space, so you must not

cannot

Am Mittwoch 02 Mai 2007 01:42 schrieb Randy Dunlap:

Quoted 4 lines

Quoted 1 line

+<title>The Userspace I/O HOWTO</title>

Most of this reads well. Thanks.
A few typo corrections are below...

Thank you for your work. I generated a new patch that includes all your suggestions and also fixes the build problems.

[...]

Quoted 11 lines

However, it still fails 'make htmldocs' for me. What am I missing? How did it work for you?
My DTD doesn't like to see <varname> inside a <listitem>:

linux-2.6.21-rc7-mm2/Documentation/DocBook/uio-howto.xml:333: element listitem: validity error : Element listitem content does not follow the DTD, expecting (calloutlist | glosslist | itemizedlist | orderedlist | segmentedlist | simplelist | variablelist | caution | important | note | tip | warning | literallayout | programlisting | programlistingco | screen | screenco | screenshot | synopsis | cmdsynopsis | funcsynopsis | classsynopsis | fieldsynopsis | constructorsynopsis | destructorsynopsis | methodsynopsis | formalpara | para | simpara | address | blockquote | graphic | graphicco | mediaobject | mediaobjectco | informalequation | informalexample | informalfigure | informaltable | equation | example | figure | table | msgset | procedure | sidebar | qandaset | anchor | bridgehead | remark | highlights | abstract | authorblurb | epigraph | indexterm | beginpage)+, got (varname CDATA)

so I removed most of the <varname>s and still had errors. Any suggestions?

Yes, this only occurs when the <listitem> content is not surrounded by <para></para>. I fixed that. I also changed the whole thing from "article" to "book" as all the other *.tmpl files are books.

[...]

Quoted 7 lines

Review

Quoted 5 lines

<listitem>
+<varname>void *internal_addr</varname>: If you have to access this memory

(quoted diff) +3 -0

+region from within your kernel module, you will want to map it internally by
+using something like <function>ioremap_nocache()</function>. Addresses
+returned by this function can not be mapped to user space, so you must not

cannot

Here I also replaced ioremap_nocache() by ioremap(). I just fixed that in uio_cif.c and don't want to encourage other people to write the same nonsense.

Here's my patch, as I said, it should include your fixes as well:

Index: linux-2.6.22-rc/drivers/uio/uio.c

Quoted 8 lines

Am Mittwoch 02 Mai 2007 01:42 schrieb Randy Dunlap:

Quoted 4 lines

Quoted 1 line

+<title>The Userspace I/O HOWTO</title>

Most of this reads well. Thanks.
A few typo corrections are below...

Thank you for your work. I generated a new patch that includes all your suggestions and also fixes the build problems.

Hi,
What does your patch apply to, please? I get patch errors with it.

Am Mittwoch 02 Mai 2007 schrieb Randy Dunlap:

Quoted 9 lines · On Wed, 2 May 2007 10:41:35 +0200 Hans-Jürgen Koch wrote:

Quoted 8 lines

Am Mittwoch 02 Mai 2007 01:42 schrieb Randy Dunlap:

Quoted 4 lines

Quoted 1 line

+<title>The Userspace I/O HOWTO</title>

Most of this reads well. Thanks.
A few typo corrections are below...

Thank you for your work. I generated a new patch that includes all your suggestions and also fixes the build problems.

Quoted 8 lines · On Thu, 3 May 2007 00:00:28 +0200 Hans-J?rgen Koch wrote:

Am Mittwoch 02 Mai 2007 schrieb Randy Dunlap:

Quoted 7 lines · On Wed, 2 May 2007 10:41:35 +0200 Hans-J?rgen Koch wrote:

Quoted 6 lines

Am Mittwoch 02 Mai 2007 01:42 schrieb Randy Dunlap:

Quoted 4 lines

Quoted 1 line

+<title>The Userspace I/O HOWTO</title>

Most of this reads well. Thanks.
A few typo corrections are below...

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Thank you for your work. I generated a new patch that includes all your suggestions and also fixes the build problems.

OK, your fixes all look good, but still needs one minor fix (below).

Acked-by Randy Dunlap <[email protected]>

Quoted 10 lines · On Thu, 3 May 2007 00:00:28 +0200 Hans-J?rgen Koch wrote:

Quoted 9 lines

Am Mittwoch 02 Mai 2007 schrieb Randy Dunlap:

Quoted 7 lines · On Wed, 2 May 2007 10:41:35 +0200 Hans-J?rgen Koch wrote:

Quoted 6 lines

Am Mittwoch 02 Mai 2007 01:42 schrieb Randy Dunlap:

Quoted 4 lines

Quoted 1 line

+<title>The Userspace I/O HOWTO</title>

Most of this reads well. Thanks.
A few typo corrections are below...

Quoted 6 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Thank you for your work. I generated a new patch that includes all your suggestions and also fixes the build problems.

OK, your fixes all look good, but still needs one minor fix (below).

Acked-by Randy Dunlap <[email protected]>

Hm, I have about 3 different patches here now, all dependant on each other, yet I can't tell which goes first :(

Can someone just send me 1, or 3 with the correct order in which to apply them?

thanks,

greg k-h

Quoted 11 lines

Hm, I have about 3 different patches here now, all dependant on each other, yet I can't tell which goes first :(

Can someone just send me 1, or 3 with the correct order in which to apply them?

thanks,

greg k-h

Hi Greg,
I attached all the UIO patches I collected so far. This is my series file:

uio.patch
fix-early-irq-problem-in-uio.patch
uio-documentation.patch
fix-uio_read-type-problem.patch
uio-dummy.patch
uio-hilscher-cif-card-driver.patch
ioremap-in-uio-hilscher-cif.patch
add-userspace-howto-to-uio-doc.patch
fix-uio-doc-build-problems.patch

It should also work without uio-dummy.patch.
I added Randy's last one-line patch to fix-uio-doc-build-problems.patch.

All patches are

Signed-off-by Hans J. Koch <[email protected]>

fix-uio-doc-build-problems.patch is also

Signed-off-by Randy Dunlap <[email protected]>

Am Donnerstag 03 Mai 2007 08:39 schrieb Hans-Jürgen Koch:

Quoted 31 lines

Quoted 11 lines

Hm, I have about 3 different patches here now, all dependant on each other, yet I can't tell which goes first :(

Can someone just send me 1, or 3 with the correct order in which to apply them?

thanks,

greg k-h

Hi Greg,
I attached all the UIO patches I collected so far. This is my series file:

uio.patch
fix-early-irq-problem-in-uio.patch
uio-documentation.patch
fix-uio_read-type-problem.patch
uio-dummy.patch
uio-hilscher-cif-card-driver.patch
ioremap-in-uio-hilscher-cif.patch
add-userspace-howto-to-uio-doc.patch
fix-uio-doc-build-problems.patch

It should also work without uio-dummy.patch.
I added Randy's last one-line patch to fix-uio-doc-build-problems.patch.

All patches are

Signed-off-by Hans J. Koch <[email protected]>

Quoted 3 lines

fix-uio-doc-build-problems.patch is also

Signed-off-by Randy Dunlap <[email protected]>

I also updated the original patch set with all these changes. They can be found here:

http://www.osadl.org/projects/downloads/UIO/kernel/

Quoted 37 lines

Am Donnerstag 03 Mai 2007 08:39 schrieb Hans-Jürgen Koch:

Quoted 34 lines

Quoted 11 lines

Hm, I have about 3 different patches here now, all dependant on each other, yet I can't tell which goes first :(

Can someone just send me 1, or 3 with the correct order in which to apply them?

thanks,

greg k-h

Hi Greg,
I attached all the UIO patches I collected so far. This is my series file:

uio.patch
fix-early-irq-problem-in-uio.patch
uio-documentation.patch
fix-uio_read-type-problem.patch
uio-dummy.patch
uio-hilscher-cif-card-driver.patch
ioremap-in-uio-hilscher-cif.patch
add-userspace-howto-to-uio-doc.patch
fix-uio-doc-build-problems.patch

It should also work without uio-dummy.patch.
I added Randy's last one-line patch to fix-uio-doc-build-problems.patch.

All patches are

Signed-off-by Hans J. Koch <[email protected]>

fix-uio-doc-build-problems.patch is also

Signed-off-by Randy Dunlap <[email protected]>

Quoted 4 lines

I also updated the original patch set with all these changes. They can be found here:

http://www.osadl.org/projects/downloads/UIO/kernel/

Can one of you make sure that Andrew has a version in -mm that will build without bombing?

Current 2.6.21-mm1 does this on UIO docs,
but all of these have been fixed via email AFAIK:

Warning(/tester/linsrc/linux-2621-mm1//drivers/uio/uio.c:240): No description found for parameter 'info' Warning(/tester/linsrc/linux-2621-mm1//drivers/uio/uio.c:594): No description found for parameter 'owner' Warning(/tester/linsrc/linux-2621-mm1//drivers/uio/uio.c:594): No description found for parameter 'info' Warning(/tester/linsrc/linux-2621-mm1//drivers/uio/uio.c:667): No description found for parameter 'info' Error(/tester/linsrc/linux-2621-mm1//include/linux/uio_driver.h:29): cannot understand prototype: 'struct uio_mem ' Error(/tester/linsrc/linux-2621-mm1//include/linux/uio_driver.h:55): cannot understand prototype: 'struct uio_info ' Warning(/tester/linsrc/linux-2621-mm1//include/linux/uio_driver.h): no structured comments found make[1]: *** [Documentation/DocBook/kernel-api.xml] Error 2
make: *** [mandocs] Error 2

drivers/uio/uio.c new file +4 -0

+static ssize_t uio_read(struct file *filep, char __user *buf,
+			size_t count, loff_t *ppos)
+{
+	struct uio_listener *listener = filep->private_data;

Quoted 10 lines

drivers/uio/uio.c new file +10 -0

+static ssize_t uio_read(struct file *filep, char __user *buf,
+			size_t count, loff_t *ppos)
+{
+	struct uio_listener *listener = filep->private_data;
+	struct uio_device *idev = listener->dev;
+	DECLARE_WAITQUEUE(wait, current);
+	ssize_t retval;
+	int event_count;
+
+	if (idev->info->irq == UIO_IRQ_NONE)

drivers/uio/uio.c line 354

Quoted 4 lines

drivers/uio/uio.c new file +4 -0

+		return -EIO;
+
+	if (count != sizeof(int))
+		return -EINVAL;

AFAIK we don't currently have any platform that runs binaries with different sizes of "int" but this is a) an unsigned value anyway, and b) should be a fixed type (eg u32)

Otherwise it looks ok at the momenmt, although there is a real nasty waiting for anyone who tries to use it. At the point open is possible or IRQs can be enabled you are safe in the core merged as idev->info is always valid, but any driver module trying to go back via info->uio_dev has a NULL pointer for an early IRQ or open event.

This means that the fasync support in the current code is basically unusable until this is fixed

Quoted 10 lines

(quoted diff) +10 -0

+static ssize_t uio_read(struct file *filep, char __user *buf,
+			size_t count, loff_t *ppos)
+{
+	struct uio_listener *listener = filep->private_data;
+	struct uio_device *idev = listener->dev;
+	DECLARE_WAITQUEUE(wait, current);
+	ssize_t retval;
+	int event_count;
+
+	if (idev->info->irq == UIO_IRQ_NONE)

Review

Quoted 4 lines

(quoted diff) +4 -0

+		return -EIO;
+
+	if (count != sizeof(int))
+		return -EINVAL;

AFAIK we don't currently have any platform that runs binaries with different sizes of "int" but this is a) an unsigned value anyway, and b) should be a fixed type (eg u32)

Otherwise it looks ok at the momenmt, although there is a real nasty waiting for anyone who tries to use it. At the point open is possible or IRQs can be enabled you are safe in the core merged as idev->info is always valid, but any driver module trying to go back via info->uio_dev has a NULL pointer for an early IRQ or open event.

Quoted 3 lines

AFAIK we don't currently have any platform that runs binaries with different sizes of "int" but this is a) an unsigned value anyway, and b) should be a fixed type (eg u32)

I reviewed the code once more and find it OK. There is only one legal value for the parameter "count" of uio_read(), and that's sizeof(int).

The data that is actually read is the element "event" of struct uio_device, which is of type atomic_t. The latter has the size of an int.

Quoted 6 lines

Quoted 3 lines

AFAIK we don't currently have any platform that runs binaries with different sizes of "int" but this is a) an unsigned value anyway, and b) should be a fixed type (eg u32)

I reviewed the code once more and find it OK. There is only one legal value for the parameter "count" of uio_read(), and that's sizeof(int).

If you are a box with multiple supported binary types how big is an "int". We use explicit sizes to ensure that uio_read() will work when/if we get platforms which support binaries with differing ideas of the size of "int". Thus it should use s32 or s64 or similar.

Quoted 6 lines

Quoted 3 lines

AFAIK we don't currently have any platform that runs binaries with different sizes of "int" but this is a) an unsigned value anyway, and b) should be a fixed type (eg u32)

I reviewed the code once more and find it OK. There is only one legal value for the parameter "count" of uio_read(), and that's sizeof(int).

If you are a box with multiple supported binary types how big is an "int". We use explicit sizes to ensure that uio_read() will work when/if we get platforms which support binaries with differing ideas of the size of "int". Thus it should use s32 or s64 or similar.

Am Samstag 28 April 2007 22:24 schrieb Alan Cox:

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

AFAIK we don't currently have any platform that runs binaries with different sizes of "int" but this is a) an unsigned value anyway, and b) should be a fixed type (eg u32)

I reviewed the code once more and find it OK. There is only one legal value for the parameter "count" of uio_read(), and that's sizeof(int).

Quoted 4 lines

If you are a box with multiple supported binary types how big is an "int". We use explicit sizes to ensure that uio_read() will work when/if we get platforms which support binaries with differing ideas of the size of "int". Thus it should use s32 or s64 or similar.

Here's a fix to that effect:

Quoted 8 lines

Am Samstag 28 April 2007 22:24 schrieb Alan Cox:

Quoted 7 lines

Quoted 6 lines

Quoted 3 lines

AFAIK we don't currently have any platform that runs binaries with different sizes of "int" but this is a) an unsigned value anyway, and b) should be a fixed type (eg u32)

I reviewed the code once more and find it OK. There is only one legal value for the parameter "count" of uio_read(), and that's sizeof(int).

Quoted 6 lines

Quoted 4 lines

If you are a box with multiple supported binary types how big is an "int". We use explicit sizes to ensure that uio_read() will work when/if we get platforms which support binaries with differing ideas of the size of "int". Thus it should use s32 or s64 or similar.

Here's a fix to that effect:

Can you please add a matching paragraph to the documentation ?

Am Samstag 28 April 2007 23:08 schrieb Thomas Gleixner:

Quoted 16 lines · Hans-Jürgen Koch

Quoted 14 lines

Am Samstag 28 April 2007 22:24 schrieb Alan Cox:

Quoted 11 lines

Quoted 6 lines

Quoted 3 lines

AFAIK we don't currently have any platform that runs binaries with different sizes of "int" but this is a) an unsigned value anyway, and b) should be a fixed type (eg u32)

I reviewed the code once more and find it OK. There is only one legal value for the parameter "count" of uio_read(), and that's sizeof(int).

If you are a box with multiple supported binary types how big is an "int". We use explicit sizes to ensure that uio_read() will work when/if we get platforms which support binaries with differing ideas of the size of "int". Thus it should use s32 or s64 or similar.

Here's a fix to that effect:

Quoted 2 lines

Can you please add a matching paragraph to the documentation ?

Yes, I'll add a "How to write userspace code" section tomorrow. I'll send a patch as soon as it's ready.

Hans

Here are the updated UIO (Userspace I/O driver framework) patches for 2.6.21.

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 ++++++++

Quoted 2 lines · 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.

Quoted 15 lines

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/

Quoted 4 lines

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?

Quoted 5 lines

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 :)

Quoted 4 lines

Quoted 1 line

 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.)

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.

On Fri, 27 Apr 2007 15:49:57 -0700

Quoted 2 lines · Greg KH

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 ;)

Quoted 16 lines

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/

Quoted 4 lines

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?

Here are the updated UIO (Userspace I/O driver framework) patches for 2.6.21.

 Documentation/DocBook/kernel-api.tmpl |    4 +
 Documentation/DocBook/uio-howto.tmpl  |  498 +++++++++++++++++++++++
 drivers/Kconfig                       |    1 + drivers/Makefile        
              |    1 + drivers/uio/Kconfig                   |   27 ++
 drivers/uio/Makefile                  |    2 + drivers/uio/uio.c       
              |  702 +++++++++++++++++++++++++++++++++
 drivers/uio/uio_cif.c                 |  156 ++++++++
 include/linux/uio_driver.h            |   91 +++++ 9 files changed,
 1482 insertions(+), 0 deletions(-) create mode 100644
 Documentation/DocBook/uio-howto.tmpl create mode 100644
 drivers/uio/Kconfig create mode 100644 drivers/uio/Makefile create mode
 100644 drivers/uio/uio.c
 create mode 100644 drivers/uio/uio_cif.c create mode 100644

include/linux/uio_driver.h

uio_dummy.c (that should be present according documentation) seems missing.

I find the doc not very clear for the devices where there is no interrupt : they speak of some kernel timer, but a userspace timer could be used (and even the userspace driver could be written without kernel support at all).

At the end of the doc there is something about IRQ_HANDLED vs IRQ_NONE. Last time I check kernel irq code, in both case next irq handler are called. The only difference was that if all handler reply IRQ_NONE, the kernel gave an error about an unexpected interrupt.

Also why sysfs is used for describing the mapping instead of something like an ioctl ?

UIO could be useful in embedded system where sysfs is not always desirable.

Here are the updated UIO (Userspace I/O driver framework) patches for 2.6.21.

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.

Quoted 11 lines · Greg KH

Here are the updated UIO (Userspace I/O driver framework) patches for 2.6.21.

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.

I have a political question, if I have a user space driver, is my kernel tainted or not? Does this open another multi-month flame war around GPL, BSD, NDA, source available but not GPL, and all the other things we talked to death about inserting non-GPL modules?

Quoted 11 lines · Greg KH

Here are the updated UIO (Userspace I/O driver framework) patches for 2.6.21.

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.

I have a political question, if I have a user space driver, is my kernel tainted or not?

Does this open another multi-month flame war around GPL, BSD, NDA, source available but not GPL, and all the other things we talked to death about inserting non-GPL modules?

Quoted 2 lines

I have a political question, if I have a user space driver, is my kernel tainted or not?

Surely not. By using the kernel's userspace interface, you create no "derived work" of the kernel. See COPYING in the root directory of the kernel sources for details.

Quoted 6 lines

Quoted 2 lines

I have a political question, if I have a user space driver, is my kernel tainted or not?

Surely not. By using the kernel's userspace interface, you create no "derived work" of the kernel. See COPYING in the root directory of the kernel sources for details.

That only covers normal system calls - but I don't think thats what is relevant, taints are for debug assistance not politics.

I think we should have a taint flag for UIO type drivers. Not for any licensing or political reason but for the simple fact it means that there may be other complexities to debugging - and not the same one as a binary module. Probably we want the same marker for mmap /dev/mem too.

Quoted 10 lines · Alan Cox

Quoted 6 lines

Quoted 2 lines

I have a political question, if I have a user space driver, is my kernel tainted or not?

Surely not. By using the kernel's userspace interface, you create no "derived work" of the kernel. See COPYING in the root directory of the kernel sources for details.

That only covers normal system calls - but I don't think thats what is relevant, taints are for debug assistance not politics.

Quoted 4 lines

I think we should have a taint flag for UIO type drivers. Not for any licensing or political reason but for the simple fact it means that there may be other complexities to debugging - and not the same one as a binary module. Probably we want the same marker for mmap /dev/mem too.

I agree, if we make it entirely clear that the flag is nonpolitical.

Quoted 11 lines · Thomas Gleixner

Quoted 10 lines · Alan Cox

Quoted 6 lines

Quoted 2 lines

I have a political question, if I have a user space driver, is my kernel tainted or not?

Surely not. By using the kernel's userspace interface, you create no "derived work" of the kernel. See COPYING in the root directory of the kernel sources for details.

That only covers normal system calls - but I don't think thats what is relevant, taints are for debug assistance not politics.

Quoted 6 lines

Quoted 4 lines

I think we should have a taint flag for UIO type drivers. Not for any licensing or political reason but for the simple fact it means that there may be other complexities to debugging - and not the same one as a binary module. Probably we want the same marker for mmap /dev/mem too.

I agree, if we make it entirely clear that the flag is nonpolitical.

Hm, I don't know, what makes this different from the fact that we can mmap PCI device space today through the proc and sysfs entries? That's how X gets direct access to the hardware for a number of different cards, and that's pretty much the same thing as the UIO interface is doing.

Unless you think we should also use the same "taint" flag on those accesses too, and if so, I have no objection.

Quoted 3 lines

Unless you think we should also use the same "taint" flag on those accesses too, and if so, I have no objection.

Right, this is just a hint, that something in user space is accessing the hardware directly. Not a too bad idea, but pretty much useless when we add X to the picture as it will be set always :)

Quoted 3 lines

Right, this is just a hint, that something in user space is accessing the hardware directly. Not a too bad idea, but pretty much useless when we add X to the picture as it will be set always :)

Index: linux-2.6.21-mm_20040728/drivers/char/mem.c
===================================================================

Quoted 8 lines

Quoted 1 line

I agree, if we make it entirely clear that the flag is nonpolitical.

Hm, I don't know, what makes this different from the fact that we can mmap PCI device space today through the proc and sysfs entries? That's how X gets direct access to the hardware for a number of different cards, and that's pretty much the same thing as the UIO interface is doing.

Quoted 2 lines

Unless you think we should also use the same "taint" flag on those accesses too, and if so, I have no objection.

Right, this is just a hint, that something in user space is accessing the hardware directly. Not a too bad idea, but pretty much useless when we add X to the picture as it will be set always :)