On Fri, Jun 24, 2011 at 9:29 AM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote: >> MythTV has a bunch of these too (mainly so the code can adapt to >> driver bugs that are fixed in later revisions). Putting Mauro's patch >> upstream will definitely cause breakage. > > It shouldn't, as ivtv driver version is lower than 3.0.0. All the old bug fixes > aren't needed if version is >= 3.0.0. > > Besides that, trusting on a driver revision number to detect that a bug is > there is not the right thing to do, as version numbers are never increased at > the stable kernels (nor distro modified kernels take care of increasing revision > number as patches are backported there). The versions are increased at the discretion of the driver maintainer, usually when there is some userland visible change in driver behavior. I assure you the application developers don't *want* to rely on such a mechanism, but there have definitely been cases in the past where there was no easy way to detect the behavior of the driver from userland. It lets application developers work around things like violations of the V4L2 standard which get fixed in newer revisions of the driver. It provides them the ability to put a hack in their code that says "if (version < X) then this driver feature is broken and I shouldn't use it." > In other words, relying on it doesn't work fine. It's the best (and really only solution) we have today. >> Also, it screws up the ability for users to get fixes through the >> media_build tree (unless you are increasing the revision constantly >> with every merge you do). > > Why? Developers don't increase version numbers on every applied patch > (with is great, as it avoids merge conflicts). The driver maintainer doesn't *have* to increase the version - he does it when he thinks it's appropriate. The point is you are taking that discretion out of *their* hands, and you yourself are unaware of when it is actually needed. You need to stop looking at this from a purist standpoint and think of how application developers actually use the API. They need tools like this to allow them to work around driver bugs while having a source codebase which operates against different kernels (including kernels that may still have those bugs). Sure, in a perfect world where drivers don't have bugs and applications don't have to run against older kernels, what you are saying is not illogical. But then again, we don't live in a perfect world. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
