Bill Dirks wrote:
>
> I think we can add application-supplied streaming buffers to the API
> without 'disturbing' the existing interface semantics. How about this:
>
...
>
> That's it.
>
> It's backward compatible all around.
Yes.
> It makes sense to me to pass the buffer on QBUF, not QUERYBUF, and no
> new REQBUFS=0 semantics is required. I understand the desire to save
> locking and unlocking the memory each time it is used, but don't think
> it's a significant overhead considering the memcpy() that is being
> avoided.
I don't agree here. If I remember correctly, the process of locking
down the user memory can be VERY expensive. Remember - it's got to be
paged in if in is not already present in physical memory. Personally, I
would really like to see those buffers locked down and left alone.
Anybody more clued up on 2.4 want to comment please?
> Having separate pointers and strides for multi-plane formats is a
> separate and orthogonal issue from whether buffers are app-allocated or
> driver-allocated.
Agreed, but how would you implement it?
> I have a couple questions.
> Is there some friendly documentation on memory locking and DMA to
> userspace in 2.4 somewhere (besides the source code)?
> What if a malicious or buggy program free()s the buffers while the
> driver still has them? Can it crash the system? Can the driver know if
> that happens like it can catch a munmap()?
Heh. Going to need someone elses input here - I have just been looking
at sample code - no specs. About the malicios free, I'm pretty sure the
kernel locks it down untild the driver releases it - should be perfectly
safe.
-justin
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
