Hi,
On 08/10/2011 02:34 AM, Theodore Kilgore wrote:
<snip>
but this is the way how the current discussion feels to me. If we agree on aiming for "doing it right" then with that comes to me doing a software design from scratch, so without taking into account what is already there.
Here, a counter-argument is to point out, as I did in a mail earlier this afternoon, that "without taking account what is already there" might possibly let one overlook something important. And, no, I am not referring to the userspace-kernelspace problem with this. I am referring to the fact that simply to dump the entire contents of the camera "into cache" (and to keep it there for quite a while) might not necessarily be a good idea and it had been quite consciously rejected to do that in the design of libgphoto2. Not because it is in userspace, but because to do that eats up and ties up RAM of which one cannot assume there is a surplus.
This is an implementation detail which has little to do with the fundamental choice of whether or not we want 2 separate drivers or 1 single driver.
In part of the snipped message you called me impatient (no offense taken), my perceived impatience is stemming from what to me feels like we are dancing around the real issue here. The fundamental question is do we want 2 separate drivers or 1 single driver for these devices.
Lets answer that first, using all we've learned from the past. But without taking into account that one choice or the other will involve re-doing lots of code, as to me that is a poor argument from a technical pov.
<snip>
There are of course limits to the from scratch part, in the end we want this to slot into the existing Linux practices for webcams and stillcams, which means:
- offering a v4l2 /dev/video# node for streaming; and
- access to the pictures stored on the camera through libgphoto
Taking these 2 constrictions into account, and combining that with my firm believe that the solution to all the device sharing problems is handling both functions in a single driver, I end up with only 1 option:
Have a kernel driver which provides both functions of the device, with the streaming exported as a standard v4l2 device, and the stillcam function exported with some to be defined API. Combined with a libgphoto2 portlib and camlib for this new API, so that existing libgphoto2 apps can still access the pictures as if nothing was changed.
Well, what I _do_ think is that we need to agree about precisely what is supposed to work and what is not, in an operational sense. But we are still fuzzy about that. For example, you seemed to assert this morning that the webcam functionality needs to be able to preempt any running stillcam app and to grab the camera. Why? Or did I misunderstand you?
You've misunderstood me. We need to distinguish between an application having a tie to the device (so having a fd open) and the application doing an actual operation on the device.
No application should be able to pre-empt an ongoing operation by another application. Attempting an operation while another operation is ongoing should result in -EBUSY.
This differs significantly from what we've currently where: 1) There is no distinguishing going on between an app having a tie and an app actually doing an operation. Only one app can have a fd open
2) Some apps (userspace apps) can pre-empt other apps, taking away their fd and cancelling any ongoing operations
The above is what leads me to me still firm believe that having a single driver is the only solution. My reasoning is as follows
1) We cannot count on apps closing the fd when they have no immediate use for the device, iow open != in-use
2) Thus we need to allow both libgphoto2 and v4l2 apps to have the device open at the same time
3) When actual in-use (so an operation is ongoing) attempt by another apps to start an operation will result in -EBUSY
4) 2 + 3 can only be realized by having a single driver
Regards,
Hans