PCI driver in userspace

PCI driver in userspace

[Daniel Shane]

Hi,

I'm looking for an example of userspace PCI driver, does anyone know where I
could find one? (Probably not in the kernel source tree, obviously).

Thanks!
Daniel Shane

Re: PCI driver in userspace

[Martin Dalecki]

Daniel Shane wrote:
> Hi,
> 
> I'm looking for an example of userspace PCI driver, does anyone know where I
> could find one? (Probably not in the kernel source tree, obviously).

XFree86 ;-).

Re: PCI driver in userspace

[Stelian Pop]

On Tue, Feb 26, 2002 at 09:55:48AM -0500, Daniel Shane wrote:

> I'm looking for an example of userspace PCI driver, does anyone know where I
> could find one? (Probably not in the kernel source tree, obviously).

There are probably better examples than mines, but you can still
look at the Andrew Tridgell's 'capture' application which drives the
PCI Motion Eye Camera device (and compare with drivers/media/video/meye.c):
	http://samba.org/picturebook/

You'll find in it quite a number of features, including i/o memory
mapping, i/o port access, etc.

Of course, one could also direct you to the XFree source code... :-)

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

RE: PCI driver in userspace

[Daniel Shane]

Thanks Stelian!

I think this is a good example to start with. It has all the
interresting features. I hope it also has interrupt handling
to userspace (by generating SIGIO's). Although I dont know
if this is a good idea in the first place.

Daniel Shane

> On Tue, Feb 26, 2002 at 09:55:48AM -0500, Daniel Shane wrote:
> 
> > I'm looking for an example of userspace PCI driver, does 
> anyone know where I
> > could find one? (Probably not in the kernel source tree, obviously).
> 
> There are probably better examples than mines, but you can still
> look at the Andrew Tridgell's 'capture' application which drives the
> PCI Motion Eye Camera device (and compare with 
> drivers/media/video/meye.c):
> 	http://samba.org/picturebook/
> 
> You'll find in it quite a number of features, including i/o memory
> mapping, i/o port access, etc.
> 
> Of course, one could also direct you to the XFree source code... :-)
> 
> Stelian.
> -- 
> Stelian Pop <stelian.pop@fr.alcove.com>
> Alcove - http://www.alcove.com
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: PCI driver in userspace

[Stelian Pop]

On Tue, Feb 26, 2002 at 12:42:26PM -0500, Daniel Shane wrote:

> I think this is a good example to start with. It has all the
> interresting features. I hope it also has interrupt handling
> to userspace (by generating SIGIO's). 

It hasn't, it just continually polls the I/O ports for 
completition.

> Although I dont know if this is a good idea in the first place.

I think it depends on the interrupt frequency, and other things.

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: PCI driver in userspace

[Pete Zaitcev]

>> I think this is a good example to start with. It has all the
>> interresting features. I hope it also has interrupt handling
>> to userspace (by generating SIGIO's). 
> 
> It hasn't, it just continually polls the I/O ports for 
> completition.
> 
>> Although I dont know if this is a good idea in the first place.
> 
> I think it depends on the interrupt frequency, and other things.
> 
> Stelian.

PCI interrupts must be deactivated in the device before an
interrupt driver returns and unmasks interrupt in the CPU.
User processes run with interrupts open. This is why purely
user level interrupts are IMPOSSIBLE (regardless of interrupt
frequency).

Two natural ways to work around this problem are:

1. Run user processes with interrupts closed (or at least one
interrupt source disabled, if your architecture allows that).
This is what RTOSes often do. I do not think it can be easily
done on generic Linux.

2. Write a small driver that deactivates interrupts and queues
interrupt events (with SIGIO and some other means). Personally,
I think that it is dumb in most cases, because once you wrote
that driver stub, it takes very little work to move the rest
of the driver into the kernel. The notable exception is XFree86,
of course.

We must ask someone to add this to FAQ on tux.org.

Very many people are psychologically afraid of drivers
(even though it's quite simple), and they wank those userspace
approaches, until they hit some brick wall (interrupts being
most common). By that time they invest so much into their code
that they are loth to abandon broken userland drivers and
start grappling about desperately for a way out.

-- Pete

Re: PCI driver in userspace

[Stelian Pop]

On Tue, Feb 26, 2002 at 07:52:39PM -0500, Pete Zaitcev wrote:

[Interrupts in userspace...]

> >> Although I dont know if this is a good idea in the first place.
> > 
> > I think it depends on the interrupt frequency, and other things.
> > 
> This is why purely
> user level interrupts are IMPOSSIBLE (regardless of interrupt
> frequency).
[...]
> 2. Write a small driver that deactivates interrupts and queues
> interrupt events (with SIGIO and some other means).

This is what I meant too, and I was talking about the interrupt 
frequency because if there are too many IT, continuous polling might
be more efficient than interrupt handling with the kernel driver + 
userspace signal sending.

> Very many people are psychologically afraid of drivers
> (even though it's quite simple), and they wank those userspace
> approaches, until they hit some brick wall (interrupts being
> most common). By that time they invest so much into their code
> that they are loth to abandon broken userland drivers and
> start grappling about desperately for a way out.

It depends on the driver. If moving _all_ the driver in kernelspace
involves putting policy and other stuff into the kernel, then no. 

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: PCI driver in userspace

[Richard Gooch]

Pete Zaitcev writes:
> >> I think this is a good example to start with. It has all the
> >> interresting features. I hope it also has interrupt handling
> >> to userspace (by generating SIGIO's). 
> > 
> > It hasn't, it just continually polls the I/O ports for 
> > completition.
> > 
> >> Although I dont know if this is a good idea in the first place.
> > 
> > I think it depends on the interrupt frequency, and other things.
> > 
> > Stelian.
> 
> PCI interrupts must be deactivated in the device before an
> interrupt driver returns and unmasks interrupt in the CPU.
> User processes run with interrupts open. This is why purely
> user level interrupts are IMPOSSIBLE (regardless of interrupt
> frequency).
> 
> Two natural ways to work around this problem are:
> 
> 1. Run user processes with interrupts closed (or at least one
> interrupt source disabled, if your architecture allows that).
> This is what RTOSes often do. I do not think it can be easily
> done on generic Linux.
> 
> 2. Write a small driver that deactivates interrupts and queues
> interrupt events (with SIGIO and some other means). Personally,
> I think that it is dumb in most cases, because once you wrote
> that driver stub, it takes very little work to move the rest
> of the driver into the kernel. The notable exception is XFree86,
> of course.
> 
> We must ask someone to add this to FAQ on tux.org.

Send me a patch to the HTML file.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca