[...]
> > 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.
>
> How about implementing a userspace daemon which does the arbitration
> between multiple users? Doing this in kernel space can get tricky, especially if
> you want to allow concurrent users with different settings, e.g. sample rate.
> This is in part due to the majority of the IIO ABI being stateless and this
> doesn't really mix well with concurrent users. Having a daemon will allow you
> to implement a stateful API on top of the stateless IIO userspace ABI.
> If you go the kernel route though I'm pretty sure you'll run into lots of
> problems without an immediate solution.
That's the direction in which we are currently advancing. Not because we are afraid of kernel-mode problems - after all they are very similar to what kernel-mode filesystem driver faces when serving multiple processes accessing the same FS, just less complicated (e.g. no writers); but mainly because we want to use existing IIO as framework.
The main drawback that we see in user-mode daemon is performance. Consider sequence of events between the daemon and the caller process:
- Caller process invokes some sort of RPC via socket/pipe/message queue [system call, context switch]
- Daemon receives request message [system call]
- Daemon pushes sample data through IPC [system call, data copy, context switch]
- Caller pops data off IPC [system call, data copy]
I.e. there are 4 system calls, 2 context switches and 2 data copies added solely for the purpose of arbitration for EACH client, even for sensors not currently shared.
BTW (not directly related), I've read somewhere that on some system IIO did up to 200M samples per second. Is it true? If yes, how such data rate was achieved?
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�����٥
