Hello Luca,
Luca Risolia a écrit :
Hello,
the project of the V4L2 library that you have proposed recently looks interesting, as I think it could solve some of the gaps in the V4L2 infrastructure in a reasonable and transparent way.
I have looked at the specifications of the library and your comments about it. I have some concerns about the explicit mention of a lock for the device handled by the base driver when it is accessed from the extended driver. In this case, the base driver is already supposed to implement the correct locking schema for the devices it handles, no matter where they are accessed from. The extended driver should forward the system calls and give the result back without adding extra locks on those devices. This is how the original V4L2 core module works too; for instance, it's perfectly allowed to open a device twice. However, this does not mean that the extended driver cannot implement locks on the _virtual_ extended devices it handles, but these locks should not interfere with the base driver.
In fact this is what I wanted to specify. The extended driver locks the base v4l driver by forwarding the "open" system call. This appears on the SD just under the "Open/close access the hardware".
Another minor issue at this stage of development is namespace for device entries. I think we should make clear to the users whether a given device node is related to the extend functionalities or not. A possible solution is to name the nodes with the pairs "/dev/extvideoX" and "/dev/videoX" (as opposite to "/dev/videoX" and "/dev/basevideoX").
Unfortunately, I do not have much time to actively code, but I will be keeping an eye on the development and send my comments when needed.
Thanks, do not hesitate to give advices. I am correcting and continuing the extension code to have something usable. I think as soon as the code will be started, this will be easier to implement the other bricks. But I have so little time that the first release is long to come :)
Best regards Luca
Cheers, Thierry