RFC usecases for simultaneous buffered / sysfs access to data

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.

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.

Quoted 47 lines

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.

Quoted 2 lines

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.

I agree. The usecases for simultaneously doing a buffer and sysfs read are rather limited. On the other hand it complicates the design and implementation.

Quoted 48 lines

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.

Quoted 2 lines

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.

I agree. The usecases for simultaneously doing a buffer and sysfs read are rather limited. On the other hand it complicates the design and implementation.

- Lars

Lars-Peter Clausen wrote on 2011-11-21:

Quoted 52 lines · Jonathan Cameron

Quoted 50 lines

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.

Quoted 5 lines

I agree. The usecases for simultaneously doing a buffer and sysfs read are rather limited. On the other hand it complicates the design and implementation.

- Lars

Agreed.