[linux-dvb] idea on how to break the static dependencies on demodulator modules

[Manu Abraham]

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