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
