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

[Jonathan Cameron <jic23@kernel.org>]

On Sun, 5 Apr 2020 11:58:38 +0200
Lars-Peter Clausen <lars@metafoo.de> wrote:

> 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.

True on both counts. For events I'm don't think this restriction really matters
because they are normally fairly tightly coupled to the data stream coming in
etc (though we should do an in kernel consumer at somepoint).  I did have a plan
a long time ago to allow additional kfifos to be attached as consumer devices
to allow more complex multi user cases if needed but never implemented it.

Lets not go down the anon route for input vs output buffers as seems entirely
reasonable that they might be used by separate programs.

Jonathan

>