Messages in this thread | | | Date | Tue, 10 Jun 2008 11:01:59 +0200 | From | "Hans J. Koch" <> | Subject | Re: [PATCH] uio_pdrv: Unique IRQ Mode |
| |
On Tue, Jun 10, 2008 at 08:11:21AM +0200, Uwe Kleine-König wrote: > > > > > > IMHO it should be asserted that irqs are on before waiting for the irq > > > in poll and read. So I suggest to call irqcontrol(ON) before doing so. > > > This should allow to work with that kind of hardware, right? > > > > Yes. But userspace can simply write() a 1 to /dev/uioX to achieve the > > same result. This would clearly show what's happening. Remember, this is > > only needed for certain (broken) hardware. If we hide some automagic irq > > enabling in the kernel, it'll become less obvious and might even have > > some bad side effects. I want to avoid this kind of trickery, especially > > as it is not needed. Userspace should use write() to control irqs. It's > > like this with any normal UIO driver, and we shouldn't have a different > > handling in uio_pdrv. > > Think of a chip that's directly connected to the bus on some embedded > > board. You use uio_pdrv to handle it. Then the very same chip appears on > > a PCI card in a normal PC. You write a normal UIO driver for it. The > > userspace part of both drivers could be exactly the same. But if > > uio_pdrv automagically reenabled the irq, we would need different > > handling in userspace, without reasons obvious to the user.
> Note that my intention is to enable irqs in uio.c, not uio_pdrv.c.
Forget it. We won't have some crap that automagically enables irqs in read() and poll(), neither with irq_enable() nor with irqcontrol(). It's not a clean solution. We now have a clean solution how userspace can enable interrupts by using write(), and this (together with uio_pdrv) can handle all cases we were talking about.
You keep arguing about code that neither introduces new features nor offers any other advantages. I'm really tired of that.
Thanks, Hans
-- 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/
| |