> -----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. Best regards, Daniel --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ��.n��������+%������w��{.n�����{��(��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
