[linux-dvb] Re: Proposal for new frontend architecture

[Michael Hunold <hunold-ml@web.de>]

Hi,

On 21.09.2004 15:49, Holger Waechtler wrote:
> > Andrews struct bus_i2c with the read and write functions is just the 
> > same as i2c_transfer(). The current frontends are i2c devices, period. 
> > So using your words it's bloat and unnecessary because the code is 
> > already there. (That the existing code is stupid in your eyes is 
> > another question).
> ?!?
You stated more than once that kernel i2c doesn't work in your eyes.

> > As I already explained in another mail, introducing a functional 
> > dependency between the frontend drivers and the dvb adapters is a 
> > no-no.  The dvb-ttpci driver would pull in nearly all existing 
> > frontend drivers with no benefit.
> nope. Each special card driver handles exactly one PCI chipset/frontend 
> combination without and if(card_type==XXX) and switch/case statements. 
> Please read the proposed code and the surrounding mails.
        MAKE_EXTENSION_PCI(fs_1_5, 0x110a, 0xffff),
        MAKE_EXTENSION_PCI(fs_1_5, 0x110a, 0x0000),
        MAKE_EXTENSION_PCI(fs_1_3, 0x13c2, 0x0000),
        MAKE_EXTENSION_PCI(unkwn0, 0x13c2, 0x1002),
        MAKE_EXTENSION_PCI(tt_1_6, 0x13c2, 0x0001),
        MAKE_EXTENSION_PCI(tt_2_1, 0x13c2, 0x0002),
        MAKE_EXTENSION_PCI(tt_2_1, 0x13c2, 0x0003),
        MAKE_EXTENSION_PCI(tt_2_1, 0x13c2, 0x0004),
        MAKE_EXTENSION_PCI(tt_1_6, 0x13c2, 0x0006),
        MAKE_EXTENSION_PCI(tt_t,   0x13c2, 0x0008),
        MAKE_EXTENSION_PCI(tt_2_1, 0x13c2, 0x1102),
        MAKE_EXTENSION_PCI(unkwn1, 0xffc2, 0x0000),
        MAKE_EXTENSION_PCI(unkwn2, 0x00a1, 0x00a1),
        MAKE_EXTENSION_PCI(nexus,  0x00a1, 0xa1a0),
        MAKE_EXTENSION_PCI(dvboc11,0x13c2, 0x000a),

There are currently 15 different cards handled by dvb-ttpci. If you 
split that up and distinguish by different frontends as well you'll 
easily get 20 different drivers.

Hmm, pci hotplugging will take care that the necessary driver will be 
loaded. If there are more drivers because of different frontends, then 
probing will do the rest.

This would involve big code restructions, so if this is really desired, 
then it should probably be done in V4.

I'm currently just trying to get V3 in 2.6 as good-working as possible, 
without wasting too much time.

> If I remember correctly they all followed the easy rule: keep it simple, 
> simplify existing code and throw away bloated code. Break API boundaries 
> where they don't make sense and introduce new ones where they stabilize 
> your system. Seperate the one-code-for-all-module into smaller ones that 
> each suit a particular well-defined and easily testable task.
The V3 API has undeniable design problems. I have a very nice living 
besides hacking Linux kernel,  so my motivation is limited in this field 
regarding V3. 8-)

> Holger
CU
Michael.