> I don't know if video_devdata() belong to the new API; however, > since i would like the driver to be compatible with as many linux2.4.x > versions as possible, i need to know: > 1. which version of the kernel the struct file_operations* interface > was introduced in; > 2. which version of the kernel the video_devdata() function > was introduced in; both in 2.4.19 (and in 2.5.x the struct file_operations thing is the _only_ available interface). > frame[i].buffer = frame[0].buffer + i * SIZE_OF_BUFFER; > > The "active and ready" frame buffer may be one of those frame[i].buffer. > > So i can mmap all the buffers (ready or not) contiguously in a single, > long virtual memory area. > > Now..Questions to the powers: is that a right way to implement mmap()? > Are there any disadvantages to allocate memory that way? Can be done that way. You should take care to page-align the buffers. That will it make easier to implement the v4l2-way to map the buffers later on (which is one mapping per buffer instead of one big mapping). Gerd -- Weil die späten Diskussionen nicht mal mehr den Rotwein lohnen. -- Wacholder in "Melanie"
