On 22/08/13 15:52, Lars-Peter Clausen wrote:
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.
The fastest way of doing this that I can see would be to allow
initialization of multiple buffers per device (not actually that
hard to do given we have the multiple stream demux there for other
reasons) and allow subsampling of the datastream in the demux. Note
that there are no assumptions that the triggering will be fixed
frequency, hence it could only be done as a filter on whatever comes up
rather than explicit frequency requests.
Does v4l handle multiple video streams to userspace at different
frame rates? That is what we are talking about here effectively.
The few times this has come up before we have always concluded that
it is better done in userspace, but there is some infrastructure in
place now that would make it 'not truly horrible' to do some of the
work in kernel.
Jonathan
--
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
