Johannes Stezenbach wrote:
Sorry, I think it is a bad idea because it is not user friendly.
The current issue is that a user doesn't know what module he is using even, he loads up a zillion frontend modules, and somebody does ask him to make changes, he does rmmod 1, 2, 3, count goes to the number of frontend dependencies. since more devices coming up, the current situation will be an even bigger pain. Imagine doing a rmmod/modprobe on the modules manually , even for development cases.
The static dependencies on the frontend drivers ensures that the necessary frontend drivers for all card variants are loaded, without users having to worry about that.
would not request_module handle that if the module is in path ?
The price to pay is a few K of wasted RAM, IMHO totally insignificant compared to the MBytes of buffer space some cards allocate.
yeah, I think memory is the last thing to look at since anyhow DVB needs more than few kB to run.
OK, in case I can't talk you out of this, what you need to do is to pull the probe code out of the demod drivers and create frontends/probe.c. Then after probing you can request_module() the necessary modules.
request_module is already used now in the current situation in the DVB_ATTACH macro, or do you mean that request module be wrapped in another function, ie, something like dvb_probe() such that even when the kernel Driver API changes we are safe to cook something else up .. ?
(I think this implies that it can't be done from a module_init() function, which I think isn't a problem for PCI or USB drivers, but could create headaches for embedded platforms. But please check, I'm not sure about this.) Also, it means that the Kconfig will still have to have the frontend dependencies. You could add a "[x] manual frontend selection for DVB experts", though.
yeah, users will need to look at dependencies issues right from the beginning or else compile all frontends as modules.
About symbol_get(): Since there only two users in the whole kernel, I recommend you check with akpm and lkml first before you base your work on it.
There is a user in kernel, before the i2c changes raged on, there was the savagefb-i2c.c doing the very same. Now it does not exist due to the i2c changes. But since we do not have a dependency on the kernel i2c implementation directly, i think we are free from that problem.
Regards, Manu _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
