Hans Verkuil wrote: > On Friday 20 November 2009 22:06:02 Devin Heitmueller wrote: >> On Fri, Nov 20, 2009 at 3:38 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >>> Hi Mauro, >>> >>> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-staging >>> for the following: >>> >>> - Enable staging drivers by default when building v4l-dvb >>> - go7007: Add struct v4l2_device. >>> - s2250: Change module structure >>> - s2250: subdev conversion >>> - go7007: subdev conversion >> I have to admit that I am not sure that enabling staging drivers by >> default is a good idea. Staging drivers can be highly unstable, and >> can potentially damage hardware. I can totally imagine less >> experienced users with one of these devices building the current code >> and then being confused why their hardware is detected but is totally >> broken, or worse becomes damaged. > > 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. Even on upstream, drivers in staging are not compiled by default. To enable them, you need to answer yes to two questions. If the driver is OK, it shouldn't be in staging. The drivers that are in staging have issues that may be just coding style, can be the usage of wrong API's, or can be something serious. Also, since the criteria for a driver to be in staging are weak, they may not be prepared to be used widely, since they is likely doing some evil things, like duplicating existing code or creating non-accepted API's. In the go7007 case, among other things, the driver duplicates existing code at the saa7115 driver still uses the already deprecated DECODER ioctl's, and creates its own API (see go7007.h). So, I'm against of enabling any staging drivers to be compiled by default. Of course, in the case of auto-compilation tests tools like what you have, it is valuable if you add a patch there that enables their compilations inside the tool, but such patch shouldn't be committed at the development tree, simply because staging drivers aren't ready yet. The developers and testers of the staging drivers should manually enable it, after being warned about the risks of using them. > 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. If the driver is being maintained, this risk is low, since the driver maintainer will take care of it. It helps if your automatic build scripts could point that the driver compilation broke for some kernels, but, as the driver is being prepared for upstream submission, the developer should already being using the latest -rc kernel for its development. If they aren't maintained, they'll be removed from staging tree on a few kernel cycles, so patches fixing the compilation for those unmaintained drivers just means that someone lost his time fixing a dead driver. Cheers, Mauro -- 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
