Perceval Anichini wrote:
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...
In that case i should be having an Alps bsrv2 demodulator chip on the
rev 1.3, rather than a ves1893. ;-)
wondering why Alps never released the above said demodulator datasheets
.. ;-)
bsrv2, bs* are all tuners from Alps , not demodulators, AFAIK. The
tuners don't do the DiSEqC but only a dedicated chip.
for example, on the Galaxis rev 1.3 FF card that i have, a LNBP13 is
used for dedicated control.
(http://pdf1.alldatasheet.com/datasheet-pdf/view/22777/STMICROELECTRONICS/LNBP13.html)
for DiSEqC.
The LNBP chip is never inside the tinbox itself.In some budget cases,
the demod can be made to do DiSEqC also without a dedicated chip (It can
be from other vendors as well). In this case, it is the demod which does
the DiSEqC, even in this case it is discrete electronic components that
do DiSEqC instead of the dedicated chip.
The term frontend, comes from the term RF frontend, which refers to the
"tinbox". In many cases the tuner/frontend (tinbox) integrates the
demod, while in some cases demodulators are outside the tuner (tinbox)
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
