[...]
> > 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.
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�����٥
