Gerd Knorr wrote: > Problems/Questions: > > * virt_to_bus() is gone in 2.4.x. It is not available any more for I still want to keep vmalloc_to_bus() for drivers that need to process the data from the hardware. I will investigate how to reimplement it without virt_to_bus(). > * What exactly is the purpose of the v4l2_q_* functions? Any reason > not to use the generic lists (linux/lists.h) instead? They do exactly what I want. > * What exactly was the reason to have one mmap() call for every > buffer instead of one big chunk like in v4l1? It just made sense to me that buffers are individually allocated and freed. I never really wanted to to use mmap() for passing capture buffers. mmap() is for mapping file contents to virtual memory, not for this. At the time there was no way to pass a user-allocated buffer to a driver, so I had to use a driver call to allocate a buffer, and mmap() was the only way. > As the drivers have to support one big chunk anyway for full > v4l1 backward compatibility, why not handle v4l2 the same way? Maybe it would have been better. > Comments? If I understand the way your registration process works, when the app calls open(), a new struct file is created whose fops->open points to video_open() in videodev.o. Then video_open() substitutes the driver fops and calls skeleton_open(). So skeleton_open() is never called directly, but always through video_open(). In that case, why not pass the video_device * to skeleton_open() to save it from having to search for its video_device *? How about changing the "video_" prefix to "v4l_" to avoid namespace conflicts with linux/drivers/video? There are already two "struct video_info"s-- in sisfb.h and videodev.h. Bill.
