Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: refactoring
Andrew de Quincey wrote:
Yeah, was pondering on whether you was arguing with me or against me :)
The #ifdef bloat won't be that much of a problem will it? The code in
question will just be a function with a #ifdef block for each frontend?
If there is only one frontend supported by an adapter, I can see no harm in
'select'ing it though.
Hi, I've just been implementing this. There is a problem with doing it using
"default".
If a user enables one DVB card, saves the config, and compiles the kernel,
everything will be fine. However, if they then enable another DVB card
requiring a different frontend, things will go wrong. The reason is that
default does not work if a value has already been set for a kernel option...
so when the first card was selected, all non-essential frontends will be
marked as "not selected". Default will not turn them on again for the second
card.
I'd rather avoid this confusion completely - most users won't care that three
frontend modules are being loaded when only one is really necessary. What I'm
going to do is turn on all frontends by default. Only the relevant ones will
actually get loaded by the cards however, so we end up in the same situation
as before.
Obviously if the user manually turns one off, they can be assumed to be
knowing what they're doing, and can sort out any problems themselves.
sounds good so far. What about adding them directly to the obj-$()-list
in the Makefile of the drivers? Since the code of most drivers is far
less than a memory page many drivers would not increase in codesize at
all (the demod code would just fill up the free space in the last page
of the driver) when the demod code gets linked directly into the card
driver module...
Holger
Home |
Main Index |
Thread Index