On 08/22/2013 04:45 PM, Drubin, Daniel wrote: > > >> -----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. 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. - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
