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

Lars-Peter Clausen
2020-04-05T09:58:43Z

On 4/5/20 11:57 AM, Lars-Peter Clausen wrote:
> 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).

And of course also that you can use `cat`, `echo`, `dd` and so on.