Linux-kernel mailing list archive 1999-37,: Re: Interrupts for userspace

# Re: Interrupts for userspace

Robert de Vries (rhdv@rhdv.cistron.nl)
Wed, 15 Sep 1999 23:01:31 +0200 (CEST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Aaron Tiensivu: "Re: NFS corruption revisited"
- Previous message: Robert de Vries: "Re: [PATCH] 2.3.18: siginfo data available for all signals"
- In reply to: Jesse Pollard: "Re: Interrupts for userspace"
- Next in thread: Jesse Pollard: "Re: Interrupts for userspace"

On Tue, 14 Sep 1999, Jesse Pollard wrote:

> --------- Received message begins Here ---------
> > 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).

Robert

    --
    Robert de Vries
    rhdv@rhdv.cistron.nl

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

- Next message: Aaron Tiensivu: "Re: NFS corruption revisited"
- Previous message: Robert de Vries: "Re: [PATCH] 2.3.18: siginfo data available for all signals"
- In reply to: Jesse Pollard: "Re: Interrupts for userspace"
- Next in thread: Jesse Pollard: "Re: Interrupts for userspace"