Re: [PATCH] uio_pdrv: Unique IRQ Mode

["Hans J. Koch" <hjk@linutronix.de>]

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