Re: RFC usecases for simultaneous buffered / sysfs access to data

[Jonathan Cameron <jic23@kernel.org>]

On 11/20/2011 12:39 PM, Jonathan Cameron wrote:
> Hi All,
> 
> One nasty issue is kicking around in how to handle in kernel interfaces.
> 
> It comes down to what happens when a sysfs read is performed on a device
> doing buffered capture.  Right now some drivers will look into the
> buffer, see if the relevant channel is there, and then pull out the
> latest reading.
> 
> Now, with in kernel push interfaces (buffer_cb etc) things are more
> complex as we have several 'buffers' and it may be that none of them
> is the traditional IIO buffer.  Thus working out whether the data is
> available anywhere is a pain.
> 
> Clearly the same issue effects other in kernel 'pull' users (which
> make direct calls to read_raw).  Now in these cases they have
> specifically requested a set of channels.  Given we have a tightly
> defined subset of channels we can add another 'buffer' that caches
> the latest value and the demux code can handle this fine. It's costly
> in terms of bus transactions, but probably the only way we can keep
> things consistent and predictable.
> 
> This approach doesn't work for the IIO sysfs accesses though as these
> frequently involve incompatible sets of channel reads (differential and
> non differential on a typical adc for example).  We simply can't do
> buffered capture of these in a single pass on some devices (max1363 for
> example).  If there is a really strong use case some sort of fallback to
> a faked 'scan' might be possible but is going to be very fiddly and in
> my view doesn't want to be in drivers unless there is a user.
> 
> 
> Hence this question comes down to what we do for iio sysfs interfaces
> and that is dependent on why people actually use the sysfs interfaces.
> 
> 1) Drop the reading from the buffer (to output via sysfs) across all
> drivers that do it. (does this hurt any one?  I wrote the first driver
> that does this and it doesn't effect any use case I have!)
> 
> 2) Implement something like in0_reserve to allow us to specify which
> channels should still be available for sysfs reads when buffered reading
> is going on.
> 
> 3) Add an iio on iio driver that uses the mapping infrastructure to
> allow it to pretend to be like the other in kernel users described above.
> 
> 
> 
> So my thoughts are that 1) is the best plan unless someone has a real
> pressing use case that requires us to read from the buffer.
> 
> We may migrate towards 3, but for now there are far too many weird and
> wonderful quirks that are not handled via the chan_spec and hence not
> available to inkernel users.  Note if we get to the stage where
> everything is well handled then there 'may' be a case for separating the
> IIO userspace access stuff out so it is 'just another' in kernel user of
> the IIO device side stuff.  We aren't there now and it won't come soon.
> 
> Option 1 also has the nice sideeffect of clearer out some fiddly code.
Also worth noting is that kfifo_buf never supported this, and that's the
buffer implementation we will be moving out of staging first.

Jonathan