On Sat, 8 Jul 2006, Andrew de Quincey wrote: > On Saturday 08 July 2006 01:51, Michael Krufky wrote: > > Andrew de Quincey wrote: > > >I wonder.. is that "unable to get function XXX" message actually useful? > > > If someone has intentionally disabled the frontends they don't need, they > > > don't want to see a load of those for the modules they intentionally > > > disabled. (some cards have 3 or 4 possible frontends, and the only way to > > > tell which is to try each in turn). > > > > Wouldn't we only see this message if the frontendfoo_attach function was > > called? This would only happen if a card is installed that needs a > > frontend driver whose support is missing. So, if the message is going > > to show, it would be for good reason. > > OK, fair enough. Now, how can we correct this for statically linked kernels > with some frontends disabled? I suppose I could put a printk in the static > inline function warning that the frontend is disabled? I'd go for that. In fact, I already suggested that: Some functionality could be added though, the empty attach functions could printk "Front-end foo support was disabled at compile time" or something like that. > I can then adjust the demodulator .h files so that it only prints this message > if the frontend is statically linked so we don't end up with TWO printouts > (one from the demod, and one from dvb_attach()). I'm not sure what you mean. dvb_attach() prints an error message if it unable to call the attach function. The stub versions of the attach functions aren't supposed to be called, they are just for linking, so they should print warning messages when called. But how can dvb_attach() fail to call the attach function, and the stub attach function get called? It seems like the two error messages are inherently mutually exclusive. I thought about the MODULES off cases a bit more: dvb_attach OFF, fecustomize OFF, modules OFF All symbol references are strong, any front-end attach() functions called MUST be there. If an attach() function is missing, the kernel will not link. dvb_attach ON, fecustomize OFF, modules OFF References to attached symbols are weak, but all attach() functions SHOULD be there. If one isn't there, due to some build flaw, the kernel _will_ link. Trying to call the missing attached function will result in the dvb_attach() "function couldn't be found" error (I think). Note that dvb_attach() will work with pre 2.6.17 kernels when modules are off. Actually dvb_attach() works fine with pre 2.6.17, it's dvb_detach() that has the problem, but only when modules are on. I think it will work even if modules are on, but module unloading is turned off. dvb_attach OFF, fecustomize ON, modules OFF The disabled front-ends, the static inline stub versions of the attach() functions are used. If one is called, it should print the "trying to use front-end that you disabled" warning. dvb_attach ON, fecustomize ON, modules OFF References to attached symbols are weak. If a disabled front-end's attach() function is called, it will get the stub version that should print the "trying to use front-end that you disabled" warning. If a non-disabled front-end's attach() function is called, it should be in the kernel. It's possible that it would not be, due to some kind of build flaw, in which case the dvb_attach() "function couldn't be found" error message will get triggered (I think). _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
