Hi Jonathan,
I am Daniel and I work with Michael.
[...]
> >This limitation is really painful for our design that is striving to
> >achieve better performance moving some of sensors logic to Kernel mode.
> >Now please Jonathan, could you explain the ratio behind this
> >limitation?
>
> Simplicity and hence speed plus where all this evolved from which was data
> logging. Technically there is nothing stopping us having a separate buffer per
> user as we already allow multiple buffers to be fed from the same device for
> different purposes. This is how the bridge to input functions (not yet in
> mainline)
>
> What is your application which needs multiple simultaneous buffered users?
We need multiple higher level clients to be able to configure the same sensor for different rates and receive data at different rates, independently of each other. I.e. device will sense at maximum of configured rates, and clients will poll data as if their configured rates. This is mainly for Android, where there are multiple sensor frameworks independent of each other.
> As a quick thought I would not necessarily be against having the ability to
> request additional chrdevs each with their own buffers. A bit fiddly to retrofit
> though as not breaking abi would mean we need to keep the existing
> interfaces as they are.
We actually thought about registering multiple "virtual" sensors for the same physical device in order to stick it into existing IIO, but that has limited use for us (in particular, we will have to only pre-register statically those multiple virtual sensors).
> >And in general - could you share with us your plans of future
> >modifications to iio
[...]
> Of course feel free to propose any changes you would like!
As of now we would like to propose an option for IIO device to allow multiple opens()s. Without that additional option devices will work as today, so that, for example, existing sensor drivers will not have to be modified for reentrancy; but those drivers that need it will signal with that option that they will handle reentrancy themselves.
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�����٥
