Re: [RFC PATCH 3/3] iio: buffer: add output buffer support for chrdev

Lars-Peter Clausen
2020-04-05T09:57:11Z

On 4/5/20 11:49 AM, Jonathan Cameron wrote:
>>> 3. A side question is about the 'iio_buffer -> pollq' field. I was
>>> wondering if it would make sense to move that on to 'iio_dev pollq' if
>>> adding multiple buffers are added per-device. It almost makes sense to
>>> unify the 'pollq' on indio_dev.
>>> But, it looks a bit difficult, and would require some more change [which is
>>> doable] if it makes sense for whatever reason.
>>> The only reason to do it, is because the iio_buffer_fileops has a .poll =
>>> iio_buffer_poll() function attached to it. Adding multiple buffers for an
>>> IIO device may require some consideration on the iio_buffer_poll() function
>>> as well.
>> I think we need one chardev per buffer. Conceptually that is the right
>> approach in my option since the two buffers are independent streams. But
>> also from a practical point of view we want to have the ability to have
>> the buffers opened by different applications. E.g. iio_readdev on the
>> input buffer and iio_writedev on the output buffer. And there might be
>> some other operations that wont multiplex as nicely as read/write. The
>> high speed interface for example would not work as it is right now.
>>
> Yup. Separate chardev is pretty much the only option given the poll infrastructure.
> In theory could do the anon file trick again but I'm not sure it's worth it
> - the vast majority of drivers are still going to be single buffer (I think!)
The main problem I see with the anon file trick is that we use the open
file also as mutual exclusion so only one application can access a
buffer at a time. This means if one application has the main chardev
open no other application will be able to access the buffers (or events).