Messages in this thread | | | Date | Wed, 15 Sep 1999 17:24:16 -0500 (CDT) | From | Jesse Pollard <> | Subject | Re: Interrupts for userspace |
| |
> From rhdv@rhdv.cistron.nl Wed Sep 15 16:02:37 1999 > From: Robert de Vries <rhdv@rhdv.cistron.nl> > On Tue, 14 Sep 1999, Jesse Pollard wrote: > > > > From: Pavel Machek <pavel@atrey.karlin.mff.cuni.cz> > > > Hi! > > > > > > > > Sorry. I of course wanted _interrupts_ to be delivered to > > > > > userspace. The code to do so (I believe it was chardevice) was already > > > > > posted to l-k but I can not find it :-(... I do not want to reinvent > > > > > the wheel. > > > > > > > > You cant do it for PCI. You have to write a custom irq handler that does > > > > all that is needed to clear the IRQ then posts something out > > > > > > BTW why not? Assuming shared interrupts: > > > > > > IRQ cames, > > > > > > my driver blocks interrupt and tells userspace > > > > > > userspace notices it is not its interrupt and tells kernel > > > > > > kernel unblocks and sends interrupt to next driver in chain > > > > > > As long as you don't share interrupt with disk driver (or if you have > > > userspace driver pagelocked), there will not be deadlocks. > > > > > > Of course it will be dog slow. It will introduce incredible > > > latencies. But it might even work. > > > > Potential deadlock is caused by the userspace process: > > 1. interrupt arrives > > 2. (other drivers called) > > 3. user space driver called > > 4. userspace driver (for some reason) needs page from disk > > 5. kernel needs new page, needs I/O > > 6. hang - IRQ not dismissed.... system dead.... > > > > Granted this is a potential, not a guranteed failure. I wouldn't want > > to share IRQs just because of the difficulty in debugging. Thats more > > for something in final integration testing, not development, which is > > all a userspace driver would be good for. > > Let me tell you a bit how User Level Interrupts (ULI) are done in IRIX 6.5 > in the React/PRO extension. > They have a few rules as to what you can do in such a beast. Firstly you > are not allowed to block. Secondly page faults are out of the question. > You have to lock memory (using mlock) you plan to use. If a page fault > occurs your app receives a SEGV. No system calls are allowed. Use of the > FPU is not allowed. > In short you can just barely set a special semaphore and do some minimal > computations and that's it. > <irony> > Gee why would they put in these restrictions.... (answer above). > </irony> > The trick is of course that these rules are strictly enforced by the OS. > And to get this enforcement is a neat trick (might not be trivial).
Yup; believe that.. It also means no debugger.... or even traces (other than somehow doing a printk... ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |