Re: Interrupts for userspace
Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Wed, 15 Sep 1999 17:24:16 -0500 (CDT)
> 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/