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

[Andrew de Quincey <adq_dvb@lidskialf.net>]

Hi, sorry about the delay in replying.

So, to summarise. Michael's patch uses the new i2c command() call to perform 
the FE identification and configuration, with the smallest number of code 
changes.

Several people then replied that the problem with doing it that way is that it 
depends on the devices being linux i2c devices and being in an x86-style 
architecture. If that is not the case, then the suggestion is unfortunately 
not useful as kernel i2c is not available/not bound to the correct adapters. 
In which case you'd have to invent another non-standard device configuration 
scheme yourself...

It also depends on being able to modify the i2c core, which may not be 
possible for proprietary manufacturers' drivers (may be bound to a specific 
kernel version, custom i2c "stack" etc).

As I see it the choices are:

1) fix v3 to work better in a non-extensible way and sort it in v4.
2) implement a "proper" way of doing it.

Option 2 requires more code changes, but, really, I doubt it would take *that* 
much longer.

If v4 isn't out soon, then people are going to have to use their own 
non-standard config schemes hacked onto v3, so I would have to say go with 
option 2. 

If its going to be out in the next month or so, then perhaps a quick fix is 
the way to do it... although then we'll _still_ have to invent a better way 
of doing it and code it up. This means more work in the long run, and means 
we'll likely break everything twice.

Personally, I'd say go for option 2 and sort it now. It's not like projects 
outwith the DVB project are gaining anything from having the frontends be 
full kernel i2c drivers - which is really the point in having such a concept.

However, I'm not sure that having one card driver per PCI chipset/frontend is 
going to work - look at the Hauppauge fullfeatured DVB-S 1.x card 
(0x13c2/0x0000) - it has the same PCI ID with multiple possible frontends. 
We'd have to support multiple frontends in that anyway, so I don't see the 
problem with keeping the same drivers supporting the same cards as they do 
now. For that one, there is no getting away from having:

 if (frontendAfound) {... } else if (frontendBfound) { ... }

so I don't see the problem in having:

if (subsysid_a) { ... } else if (subsysid_b) { ... }

as well. 

Having separate drivers for each PCIID/frontend is a stylistic change rather 
than an essential improvement. It also means that when we release that 
version, many end-user configurations will likely cease working (although PCI 
hotplug may help somewhat here, if it is enabled). For the frontend changes, 
this isn't the case as we'll be explicitly request_module()ing them (or 
whatever), so it doesn't really matter if we change their names. 

Although it does mean we still have some hairy bits of code in the dvb card 
drivers, I would rather only have to deal with one set of refactoring tasks 
at a time. IMO, this is the sort of change that should definitely be left for 
v4.