Re: working with IIO

[Lars-Peter Clausen <lars@metafoo.de>]

On 08/22/2013 05:16 PM, Drubin, Daniel wrote:
> [...]
>>>  From practical POV we don't have much choice (timeline), since we have to
>> reuse driver that is bound to IIO. From principle standpoint I somehow fail to
>> see a problem. It seems to me that all state handling that an IIO driver needs
>> to do is to keep associations of PIDs to sensor rates, configure sensor to the
>> highest rate in the list and replicate shared data at rates requested by the
>> clients. When a file descriptor is closed (due to process termination or
>> another reasons), the actual sensor is re-configured with next-highest rate
>> among the open FDs.
>>
>> But you can't track the configured rate per PID with the current API. That's
>> why I keep saying that the API is stateless. You can not track state per
>> application without inventing a new API.
>
> Why can't I during keep a list of PIDs that currently use a sensor and record current->pid together with "default" rate during the first sampling request that doesn't have a matching PID, and in write_raw() handler that updates rate match that current->pid against list of recorded PIDs? I didn't see a possibility that sensor driver's handler may get called in a different context than IIO core fops handler.

So each time a process writes to a IIO sysfs file you want to record which 
value that application wrote. So when I run `for i in `seq 0 100000`; do echo 
$i > sampling_frequency; done` I'd end up with a list with one million entries 
which will stay in the list forever.

- Lars