On Fri, Nov 20, 2009 at 4:45 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > If there are drivers in the staging tree that are so unreliable that they > can break the hardware, then those should be explicitly disabled, rather > than disabling all drivers in the staging tree. Or perhaps do not belong > there at all, or belong under the CONFIG_STAGING_BROKEN option. > > A driver like the go7007 is under active development, and it does work. It > only needs more cleanup before it can be moved to drivers/media/video, so > there was no reason that it should be disabled. > > Mauro, what are the risks of always compiling the tm6000 and cx25821 > drivers? Let me know if you think that either one or both should be > disabled for now and I'll make a patch for it. I'm certainly much more worried about the tm6000 stuff than the cx25821, primarily because the cx25821 is pretty rare and the tm6000 is used by several fairly popular consumer products, but is completely broken. >> I agree that we should be periodically ensuring the modules still >> compile, but I think that by default they should need to be explicitly >> enabled by a developer who knows what he/she is doing and understands >> the ramifications/risks. > > By not compiling you run the very high risk of bit rot: code getting > seriously out-of-sync with the rest of the tree. Possibly requiring a lot > of work later. Our tree is primarily for developers, not for end-users. So > we need to see any code breakages as early as possible. Sure, in a perfect world that would be true. In reality though, I'm confident that a *huge* percentage of people who compile the v4l-dvb code have absolutely no idea what the hell they are doing. They are end-users who just want to see their device work because the changes haven't made it into their distro yet. I can certainly appreciate the concerns about the bit-rot issue. I am just worried that perhaps we set the bar too low in terms of what got into staging if it's going to be compiled by default. 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
