Vladimir,
Your proposal for the capture API via memory mapped buffers makes some rather
naive assumptions about the order in which certain operations take place,
resulting in a very real possiblity of unavoidable race conditions, and data
corruption.
You wrote:
When capturing video the application will read data from the buffers
until it encounters one with smaller serial number and/or marked as busy.
It then has an option to do something else and/or issue a request
on control interface to notify when more data is available.
So, at the very least, the application has to read two fields from the
struction, and test them, in order to stop capturing. The problem is that
reading fields out of memory is not an atomic function. So, if you
application does something like:
if( !header->busy) /* HERE! */
if(header->number > previous_frame)
{
capture_frame();
}
If an interrupt occurs where I marked "HERE!", and the driver starts a DMA
operation into the buffer being tested, bad things will happen. The results
will depend on the driver's implementation, on the device in question, and on
sheer luck. As an example, the driver could mark the buffer 'busy', set the
frame number, and start reading data, returning control to the user process
before it's done reading. (This can happen with a bus mastering device). Now,
the frame number is current, the second if() succeeds, and capture_frame()
will capture something incoherent.
Also, I'm not sure how you can write device independant user code using your
approach. It reminds me of several Microsoft API's I've worked with in the
past (DirectX and SAPI come to mind), where driver implementers were given so
much freedom in choosing which parts of the API to implement, that driver
independant user code became either hard (in the case of DirectX) or
impossible (SAPI) to implement.
It also sounds a lot like what I read about Plan 9, which I haven't worked
with. I hear that's not a bad thing.
Ori Pessach
volodya@xxxxxxxxxxxxxx wrote:
> After looking at and working with Xv, v4l and v4l2 I became somewhat
> dissatisfied with the current state of affairs. I have attached a
> description of the API that would make (at least) me much happier.
>
> I would very much appreciate comments from interested people..
>
> thanks !
>
> Vladimir Dergachev
>
> ------------------------------------------------------------------------
> Name: km.rfc.txt
> km.rfc.txt Type: Plain Text (TEXT/PLAIN)
> Encoding: BASE64
> Description: RFC: Kernel multimedia API (km.rfc.txt)
