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
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
