Hej, On Mon, Sep 03, 2012 at 01:36:53PM +0100, Sean Young wrote: >On Sun, Sep 02, 2012 at 11:08:20PM +0300, Timo Kokkonen wrote: >> I guess the assumption is to avoid >> breaking the transmission in the middle in case the process is signaled. >> And that's why we shouldn't use interruptible waits. >> >> However, if we allow simply breaking the transmitting in case the >> process is signaled any way during the transmission, then the handling >> would be trivial in the driver. That is, if someone for example kills or >> stops the lirc daemon process, then the IR code just wouldn't finish ever. >> >> Sean, do you have an opinion how this should or is allowed to work? > >You want to know when the hardware is done sending the IR. If you return >EINTR to user space, how would user space know how much IR has been sent, >if any? > >This ABI is not particularily elegant so there are proposals for a better >interface which would obsolete the lirc interface. David Hardeman has >worked on this: > >http://patchwork.linuxtv.org/patch/11411/ > Yes, the first step is an asynchronous interface using a kfifo which is managed/fed using functionality in rc-core and drained by the drivers. The size of the kfifo() itself is the only limiting factor right now, but I do think we should eventually add some restrictions on the combined duration of the pulse/space timings that are in the queue at any given point. Say, for example, that any given pulse/space value is not allowed to be above 500ms and the total duration of the queue is not allowed to be above 1000ms. In case user-space wants (for whatever reason)...to write a 4000ms space, it would have to do so in 8 messages of 500ms each. Each message write() provides the opportunity for a interruptible wait (in the regular case) or returning EAGAIN (in the O_NONBLOCK case) - assuming that the kfifo already holds pulse/space timing totalling 1000ms and/or is full. EINTR should only be returned if nothing has been written to the kfifo at all. That way we would avoid policy in kernel while still making it possible to kill a misbehaving user-space process by forcing it to drip feed long TX sequences. -- David Härdeman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
