Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>
>
>"Drubin, Daniel" <daniel.drubin@xxxxxxxxx> wrote:
>>[...]
>>> Not for replicating the
>>> >same mmap()ed data for multiple clients of course, but IIRC yes,
>v4l
>>> >allows multiple channels to be opened. E.g. for peeking full video,
>>> >preview and teletext or for switching between video sources on the
>>same
>>> >grabber. Making the whole major node singleton is a bit harsh
>>> >restriction IMHO.
>>> Sure to that but here equivalent is opening main stream an pulling
>>out
>>> different frame rates. Equivalent of your example is a multiple
>>sample rate
>>> hardware device. Those are handled using multiple instances of
>>iio_Dev.
>>
>>We actually considered creating a separate iio_dev per "virtual"
>sensor
>>(pair of {sensor, rate}). The problem is, they can pop-up dynamically
>>and even if we opened a backdoor interface of silently creating new
>>chardevs, we can't eat up all major numbers in the system. And we can
>>get dangerously close to that :-(
>
>Not a problem as can create anonymous ones like we already do for
>events.
>
>Now how you control which channels go where is harder as normally we do
>this sysfs and I would be very dubious about changing that. It could
>obviously be done but I can't think of a clean way of doing it.
>
>Just how many readers are we talking?
Note I agree with Lars that this probably better done in user space. I just find the idea of doing it in kernel space interesting!
>>
>>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�����r��y���b�X��ǧv�^�){.n�+����{��*"��^n�r��z���h����&�� �G���h�(�階�ݢj"���m�����z�ޖ���f���h���~�m
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
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
