Re: User mode drivers: part 1, interrupt handling (patch for 2.6.11)
From: Jon Smirl
Date: Sun Mar 13 2005 - 20:52:42 EST
On Mon, 14 Mar 2005 11:39:00 +1100, Peter Chubb
> >>>>> "Jon" == Jon Smirl <jonsmirl@xxxxxxxxx> writes:
> Jon> On Fri, 11 Mar 2005 11:29:20 +0100, Pavel Machek <pavel@xxxxxx>
> Jon> wrote:
> >> Hi!
> >> > As many of you will be aware, we've been working on
> >> infrastructure for > user-mode PCI and other drivers. The first
> >> step is to be able to > handle interrupts from user
> >> space. Subsequent patches add > infrastructure for setting up DMA
> >> for PCI devices.
> >> >
> >> > The user-level interrupt code doesn't depend on the other
> >> patches, and > is probably the most mature of this patchset.
> >> Okay, I like it; it means way easier PCI driver development.
> Jon> It won't help with PCI driver development. I tried implementing
> Jon> this for UML. If your driver has any bugs it won't get the
> Jon> interrupts acknowledged correctly and you'll end up rebooting.
> That's not actually true, at least when we developed drivers here.
> The only times we had to reboot were the times we mucked up the dma
> register settings, and dma'd all over the kernel by mistake...
The way you can avoid reboot is to leave the interrupt turned off at
the PIC. The side effect is that everything else using that interrupt
is also turned off.
I did experiment with catching the process exit from the user space
app on abort. Then I used the power control registers to turn off the
card if it supported being turned off. That would then safely let me
reenable the pick.
This code needs to refuse to attach to a shared IRQ until problems
with them are fixed. Most IRQs are shared on x86 desktops. Every
machine I have around here has no free IRQ's available.
> Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
> The technical we do immediately, the political takes *forever*
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/