> > 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. I don't see the paging in as a big problem. If you do streaming capture your buffers should'nt get swapped out as they are accessed all the time (as long as you are using the same set of buffers). Remaining overhead is page table lookups + (for bt848) risc code generation. Even that can be reduced. We could use a flag for that. If a application plans to reuse that buffer some hint flag can be set, and the driver can keep the buffer locked down then. Not forever (that would allow a nice DoS), but for - say - a second. Long enouth that we don't have to lock it again if the app does streaming capture. Gerd -- Get back there in front of the computer NOW. Christmas can wait. -- Linus "the Grinch" Torvalds, 24 Dec 2000 on linux-kernel
