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
-
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/
This archive was generated by hypermail 2b29 : Thu Feb 28 2002 - 21:00:35 EST