On Tue, Aug 21, 2012 at 01:55:12PM +0100, Sean Young wrote: >On Mon, Aug 20, 2012 at 07:02:47PM -0300, Mauro Carvalho Chehab wrote: >> Em 20-08-2012 18:36, David Härdeman escreveu: >> > On Thu, Aug 16, 2012 at 08:12:34PM -0300, Mauro Carvalho Chehab wrote: >> >> Em 16-08-2012 19:15, Sean Young escreveu: >> >>> Could we have a flag in rc_dev to signify whether a driver blocks on >> >>> completion of a transmit and only sleep here if it is not set? >> >>> >> >>> e.g. rc_dev.tx_blocks_until_complete >> >>> >> >>> The wording could be improved. >> >>> >> >>> Another alternative would be if the drivers provided a >> >>> "wait_for_tx_to_complete()" function. If they can provided that; using >> >>> that it would be possible to implement O_NONBLOCK and sync. >> >> >> >> Seems fine on my eyes. It may avoid code duplication if you pass the fd >> >> flags to the lirc call, and add a code there that will wait for complete, >> >> if the device was not opened in block mode. >> > >> > I think a future rc-core native TX API should behave like a write() on a >> > network socket does. >> > >> > That is, a write on a rc device opened with O_NONBLOCK will either >> > succeed immediately (i.e. write data to buffers for further processing) >> > or return EAGAIN. A write on a non-O_NONBLOCK device will either write >> > the data to buffer space and return or wait for more space to be >> > available. No waiting for the data to actually leave the "device" (NIC >> > or IR transmitter) is done by the write() call. > >The waiting for the data to leave the device could be enforced by opening >with O_SYNC or fsync(). I agree with O_NONBLOCK being better for blocking >on outgoing buffer space.
I don't think we should support O_SYNC at all unless there is a compelling use-case for it. I seriously doubt there is one. A rc device has more in common with a socket() than a open():ed file which resides on a harddisk. The O_NONBLOCK case is useful for e.g. a future lircd which uses some kind of epoll() event loop to write TX data, read RX data and to send/receive commands to/from userspace. The non-O_NONBLOCK case is useful to e.g. a debug command line program which does a blocking write and returns once the entire TX data stream has been passed to the kernel (eg some kind of rc_tx tool which could be used in scripts). >We could also have a kernel space write buffer (kfifo?) which the device >driver works its way through; user space would just have to make sure >the buffer doesn't deplete, but there would be no limit on the IR signal >including silences. In that way the timing is entirely done in kernel >space and no need for awkward sleeps and crossing of fingers. That is what I've proposed (in the patchset I've already sent, a kfifo is used for TX and trailing silences and/or inter-command silences can be encoded in the TX data itself). >> The lirc interface may not be the right device for such usage, >> if changing it would break support for existing devices. > >It would be great to obsolete that interface. Could reading raw IR be >merged with the input interface? No, it should be done using a separate RC-specific device...because we should support multiple input devices per RC device and not pollute the input subsystem with rc specifics. -- David Härdeman -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
