Michael Schimek wrote:
> 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. ;-)
Ok, I'll try to write down what I know / have figured out. Alan, please
correct me if I'm wrong.
Right now I have just a single hackish ioctl in bttv which does everything
in one go. Just for playing and to look how this stuff works...
> So far I understand kiobuf has nothing to do with the userland
> readv/writev.
Exactly. You don't memcopy stuff from kernel to user, but let the hardware
write directly to userland memory.
> 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.)
We still need VIDIOC_REQBUFS (which locks down the cpature parameters).
But instead of mmap'ing all buffers the application could pass a list
memory blocks it wants to use. The driver can create kiobufs for them
at this point (with alloc_kiovec() + map_user_kiobuf(), see linux/iobuf.h).
> The app calls the queue ioctl passing a pointer to user memory and its
> size.
Or just the buffer number of a previously registered buffer.
> 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?
lock_kiovec() faults the pages and locks them in memory, so it is safe
to let the hardware write to them. IMHO we can let choose the driver
whenever it wants to lock down all buffers at VIDIOC_STREAMON time
(and unlock on VIDIOC_STREAMOFF) or if it prefeares to lock down the
individual buffers if they get queued and unlock them when finished.
The latter implies that the physical memory of the buffer might have
changed the time it gets queued the second time.
> Q: What happens if the app frees memory (e.g. shmdt, unmap) while a DMA
> is underway?
Don't know. I'd expect map_user_kiobuf() increases the pages reference
counter, so they would'nt be released until you unmap_kiobuf() them even
if the application does evil things...
> What if the target is out of DMA range e.g. 16M, 4G or some
> weird device memory?
No code yet for this. Device memory would'nt work anyway I think
(hmm, maybe we need both mmap() and kiobufs then? Are such devices
out there?).
> Can kio swap pages around to move them in place,
That would IMHO be the best way to handle it as bounce buffers would kill
performance. But you will win only if you reuse buffers, for a single
capture I'd expect swapping pages to get them below 4G is more expensive
compared to a bounce buffer and a single copy.
But I don't know enouth details about the linux mm system...
> or
> even create large chunks of physically continuous memory or must the
> hardware support page granularity scatter and gather?
Right now it does'nt do any magic, i.e. the hardware must support
scatter/gather.
> What happens if
> the memory is all zero and refers to the same zero page, will it
> allocate enough pages?
lock_kiovec() should handle this I think.
> What if the pointer does not refer to memory but
> a mmap'ed file?
Hav'nt tried but IMHO it should work. lock_kiovec() faults the pages
into memory, the next msync or munmap should flush the new content
to disk. Hmm, while thinking about it: Someone would have to mark
the pages as dirty, right? Who does?
> Would e.g. images written into buffers be stored on disk
> or sent over IP?
IP? Can you mmap IP packets?
> Is it possible to map and lock pages of a vector
> individually or just the whole vector at once?
You can lock at iobuf granularity. If you have a iobuf for every page
and group them into one iovec, you can lock every single page. It is
probably more useful to create a iobuf for every capture buffer and
group these into one iovec.
> > 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>?
Ah, that was the trick, I remember. Thanks. I'll upload bttv-0.7.34
later today.
Gerd
--
Protecting the children is a good way to get a lot of adults who cant
stand up for themselves. -- seen in some sig on /.
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
