On Sat, 6 Oct 2007, Ingo Molnar wrote: > FYI, just found this V4L build failure in -rc9: > > drivers/built-in.o: In function `saa7146_unregister_device': > : undefined reference to `video_unregister_device' > drivers/built-in.o: In function `saa7146_register_device': > : undefined reference to `video_device_alloc' > drivers/built-in.o: In function `saa7146_register_device': > : undefined reference to `video_device_release' > [ ... etc ... ] > > this is caused by the attached config: > > CONFIG_VIDEO_BUF=m > CONFIG_VIDEO_BUF_DVB=m
video_unregister_device, etc. are from CONFIG_VIDEO_DEV, not COFIG_VIDEO_BUF. VIDEO_SAA7146_VV does need VIDEO_BUF, but that's not what's causing the undefined references above. I do not think VIDEO_BUF_DVB is needed by VIDEO_SAA7146 or VIDEO_SAA7146_VV, but some others drivers which use saa7146 do need it. > combined with: > > CONFIG_VIDEO_SAA7146=y > CONFIG_VIDEO_SAA7146_VV=y > > so it seems like a drivers/video/Kconfig bug - this combination should > not be possible. The config has these two settings: CONFIG_VIDEO_SAA7146_VV=y CONFIG_VIDEO_DEV=m VIDEO_SAA7146_VV _does_ depend on VIDEO_DEV. The Kconfig file does not allow for this setting, yet your config has it. The reason is because some other drivers select VIDEO_SAA7146_VV. I think the fundamental problem here is the way Kconfig handles "select" operations. If one turns on an option that selects another, then the selected option will always be turned on, even if *its dependencies are not satisfied*. That is what has happened here. Something has selected VIDEO_SAA7146_VV=y, when its dependency on VIDEO_DEV should not allow it. IMHO, the real solution here is that Kconfig should recursively follow select operations either up or down the stack. One way to do it, would be if FOO selects BAR, then FOO also selects everything that BAR depends on. Another way, would be that if FOO selects BAR, then FOO also depends on everything BAR depends on. It appears the way this is handled now, is to do the second method manually in the Kconfig file. In this case, anything which selects VIDEO_SAA7146_VV needs to depend on VIDEO_DEV and anything else VIDEO_SAA7146_VV depends on. Now, most of the things that select VIDEO_SAA7146_VV try to do this, but it doesn't work because of another issue "tristate to bool promotion", which has caused problems before: http://lkml.org/lkml/2007/6/23/244 config DVB_AV7110 tristate depends on VIDEO_V4L1 select VIDEO_SAA7146_VV config VIDEO_V4L1 bool depends on VIDEO_DEV config VIDEO_DEV tristate In this case AV7110 depends on V4L1, which depends on VIDEO_DEV. So AV7110 should recursively gain a dependency on VIDEO_DEV. But because V4L1 is a bool, it's possible to set VIDEO_DEV=m and VIDEO_V4L1=y, which then allows DVB_AV7110=y. So now we have DVB_AV7110=y and VIDEO_DEV=m, which shouldn't be allowed. I wonder if an easy solution to this, would be to allow bools to take the value of 1 aka 'm'? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
