> -----Original Message----- > From: Lars-Peter Clausen [mailto:lars@xxxxxxxxxx] > Sent: Thursday, August 22, 2013 5:17 PM > To: Drubin, Daniel > Cc: Jonathan Cameron; Yuniverg, Michael; linux-iio@xxxxxxxxxxxxxxx; > Haimovich, Yoav > Subject: Re: working with IIO > > On 08/22/2013 03:39 PM, Drubin, Daniel wrote: > > [...] > >>> 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 problem is that the IIO ABI is stateless, so either you need to add some > very crude hacks on-top of it to allow this or you'd have to throw away the > current ABI and develop a IIOv2. The userspace daemon is in my opinion > preferable to both cases. >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. > > 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. > > If done right the overhead should hopefully be negligible. E.g. right now we > do not have mmap support for IIO, but this is something that will be > implemented sooner or later (probably sooner than later). I think we should > take a look at how ALSA does these things. There we also have no in-kernel > multiplexing or mixing and things are handled by a userspace daemon. It's not that negligible. We are developing a sensors hub, not individual sensor. So we are required to withstand about 10 sensors simultaneously, most at approx. 400 samples/s. Linux is not extremely good at context switching latencies, so we are afraid that this overhead multiplied by number of concurrently used sensors may become a real obstacle. I don't know ALSA too well, and audio sampling may be too low-rate to be relevant in this context. I can suggest looking at V4L(2) instead - its concise interface capable of handling large amounts of timely data is over-decade proven. 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�����٥
