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

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

Hi,

On 21.09.2004 15:00, Holger Waechtler wrote:
> Michael Hunold wrote:
> > I didn't want to waste a lot of time separating the stuff, so the 
> > easiest way was to export the ID for now.
> >
> > Of course dvb_stv0299 should look more like this:
> > [...]
> I still can't see the point of your argumentation, what exactly is the 
> advantage over the trivial implementation proposals Andrew posted?
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).

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.

I'd like to hear what Andrew and Johannes think of this.

> maybe you may also take a look into other software architecture books, 
> Kent Beck's "Extreme Programming" is a nice lecture covering these 
> topics. Don't remember the exact title, it's some years ago that I read 
> it. You'll probably also find a lot of texts on the web.
Been there, done that. You probably know Martin Fowler: Refactoring. 
Improving the Design of Existing Code, Addison-Wesley Professional 1999, 
ISBN 0201485672, where the ideas are presented in cooking recipes.

I don't know if any of that recipes really fits in here, because we have 
some subsystem boundaries here, which cannot shuffle around easily. Of 
course this is only true if we want to stick with kernel i2c.

> Holger
The kernel i2c guys have just answered my proposal on the command 
function in struct i2c_adapter. They're very interested in the topic, so 
 I'll CC linux-dvb in my future answers.

CU
Michael.