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