Hello !
> > > What about doing things the old fashioned way, with a library? Stick all the
> > > nim (WTF is nim?) code into a directory, one nim per c file, and compile them
> > > all into a nim.a library. Then each driver can link against nim.a and will
> > > get the nim functions it needs, and not the ones it doesn't. The prototypes
> > > could be in a single nim.h, or in nim_{foo,bar,baz}.h for each nim.
[...]
> Seems to work fine. I added non-static global functions with the same name to
> two modules, and they loaded fine, each calling their own version of the
> function. Not exactly the same as pulling the function in when the module
> is linked at compile time, but I think that will work too.
Using a static library will duplicate binary code into different
modules as well, no ?
Couldn't we build a single 'frontends' module that would
include all tuners and demodulator selected by the user during the
kernel configuration step ?
For example, for a TT card, the following modules would be loaded :
budget.ko
frontends.ko (including stv0299 and bsbe1 code...)
This reduces the number of modules to be loaded, but have the flaw
to kinda obfuscate which tuners are really available in the system...
Well, this may not a so good idea, as 'obfuscation' is a word that
shall not apply in the kernel.
Another idea would be to compile the extra chip (I don't like the
'tuner' name, I'll explain that below), directly in the frontend
using it (Ok, now I'm really lost between this frontend/tuner/stuff)
I explain : Maybe the bsbe1.h, bsrv6 stuff shall be included in the
STV0299 (This is not a tuner nor a frontend but a demod, no ?)
module ???
What I'm sure about is that using small header containing static
code like Oliver did has several advantages :
- It works fine !
- The code dedicated to a single tuner is centralized in a single
dedicated file which is IMHO loveable -> no need to grep loads
of file to know where relevant code is !
- It allows to move easily the duplicated code in a single place.
- It does not imply Makefile modifications.
- If we find the good idea to avoid binary duplicated code,
it will be easy to applies, as all the code related to tuners
lies in a single place.
Therefore, maybe we could finish to move all the 'tuner' stuff to
frontends/, and then have a look of what could really be done to
improve that binary code duplication ?
For prefix suggestion, 'tuner-' seems a bit reductive for me : For
example the bsbe1 chip also handle LNB control and DISECQ. Are these
functionality really belong to the tuner stuff ? For me a
'tuner' is only related to HF stuff. To my mind a frontend is made of
Tuner + Demod + LNB control + optional DISECQ stuff. Do not hesitate
to tell me if, I'm wrong somewhere...
If the purpose of the prefix is to tell what kind of function
the chip 'drivered' (new word !) in a file handles, i guess that we'd
have to add some more prefixes : tuner-lnb-disecq-bsbe1.h. A bit verbose
isn't it ?
Moreover most people looking for the implementation of one of these
chips will know the chip reference. If I need to check the code for my
card that have a BSBE1 chip, I'll go read the bsbe1.h file directly.
In that case the tuner- prefix seems not necessary.
For the other case I see, "what is implemented in this bsbe1.h
file???", opening the file to look at the documentation seems not
a too much heavy process... Maybe a bit of improvement of the
documentation in the files (like adding a reference to the datasheet
if available) would be a good thing ? Or maybe an addendum to the WIKI ?
Perceval.
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
