> "Resist the urge to wrap buffers of data in any kind of "helper" object: let > the application provide its own pointers to malloc()ed memory to receive the > video data, or from which to read video data. I know that paper, someone posted that url here a few days ago. How do you solve the problem that your malloc()ed memory might not be non-DMAable memory? bounce-buffers? Naa, that would suck performance-wise. This is exactly what bttv does if zerocopy DMA doesn't work if you read() a frame, but I don't think that this is a good solution for streaming capture. > Further down he states that constraints on the memory passed to the device > are fine (byte alignment, etc. ). Alignment isn't a big issue, shmget() gives you page-aligned memory. > It would be fair enough to state that the memory's real address needs to be > below the 4G line. Ok, how an application can do that? malloc() memory which is gurantied to be below 4GB in physical memory? And where does a application know these limitations? They are architecture-dependant. sparc64 for example has a iommu and thus 32bit pci devices can reach the whole address space. > Then we should figure out a way to ask the OS for memory > that will always be guaranteed to fit the restraints require by the system, > or fail cleanly. This is where Mr. Cox could help out a bit. There is already such a way: mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, "/dev/video", off). This does basically the same as mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED | MAP_ANON, -1, off). with the main difference that bttv takes care to allocate pages it can DMA to (i.e. no highmem). And other drivers can do simliar things ... > complexity of a running system is where you get hurt. But as long as the > driver is explicit in its error codes, who cares? The users which have to deal with the broken applications (which don't check the error codes, quite common unfortunaly). Gerd -- #include </dev/tty>
