On 08/22/2013 05:48 PM, Drubin, Daniel wrote:
-----Original Message-----
From: Lars-Peter Clausen [mailto:lars@xxxxxxxxxx]
Sent: Thursday, August 22, 2013 6:42 PM
To: Drubin, Daniel
Cc: Jonathan Cameron; Yuniverg, Michael; linux-iio@xxxxxxxxxxxxxxx;
Haimovich, Yoav
Subject: Re: working with IIO
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.
No, there is only one entry per PID. Next value that the same process writes will replace the previous one, not create a new entry. An entry will be create only if the write request arrived from a PID currently not in list.
Assume that echo is a /bin/echo, not a shell built-in command.
- 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
