Gerd Knorr wrote:
>
> > Where can I find an introduction to kiobufs?
>
> Other peoples source code...
Duh. You seem to know quite a bit, I hope you don't mind if I ask you an
ear off, that's easier. ;-)
So far I understand kiobuf has nothing to do with the userland
readv/writev. Transposed to v4l2 it would work for example like this:
After format negotiation between the app and driver and other pre-work,
the ioctl requesting buffers and mmap'ing them individually is omitted.
(This needs a thought, requesting buffers used to lock certain
parameters.)
The app calls the queue ioctl passing a pointer to user memory and its
size. The driver verifies they are valid and with kio it maps the memory
into kernel space (why, when it needs just the physical address?) and
locks the pages in physical RAM. This may require page swapping, no
matter.
The driver queues the buffer in his "ready" queue, after it's been
filled and stamped moves it to the "done" queue and unmaps. poll()
notifies the app, it dequeues, and so forth. Right?
Q: What happens if the app frees memory (e.g. shmdt, unmap) while a DMA
is underway? What if the target is out of DMA range e.g. 16M, 4G or some
weird device memory? Can kio swap pages around to move them in place, or
even create large chunks of physically continuous memory or must the
hardware support page granularity scatter and gather? What happens if
the memory is all zero and refers to the same zero page, will it
allocate enough pages? What if the pointer does not refer to memory but
a mmap'ed file? Would e.g. images written into buffers be stored on disk
or sent over IP? Is it possible to map and lock pages of a vector
individually or just the whole vector at once?
> While talking about bttv-0.7.34: I'm busy with splitting the thing
> into multiple source files and ran into this problem with 2.2.x:
Did you add #define __NO_VERSION__ (read: in this file) before #include
<linux/module.h>?
Michael
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
