[linux-dvb] Re: refactoring

[Holger Waechtler <holger@qanu.de>]

Gerd Knorr wrote:

> > > Have you actually looked at my cx22702 version?
> > > There is much generic, reusable code in there.  And it is generic
> > > *because* it makes heavy use of the kernl i2c infrastructure.
> > >      
> > no. that's just the reason why it's not portable, not testable in a 
> > userspace mockup and hardly portable to other OSes like MacOS-X and BSD. 
> > The new approach without dependencies to kernel APIs is much nicer.
> >    
> You lose portability yes.  I don't care much, especially in case of the
> cx88 driver which is linux specific anyway.  I want to be able to write
> a *good* linux driver, with full suspend+sysfs support, and I simply
> have to use the kernel i2c infrastructure for that.
>  
no, you don't have to. Finish the dvbdev sysfs implementation and you 
will get proper sysfs nodes even for you demod, decoder and networking 
devices, not only for the frontend.

> Andrew's approach might be easier to understand on a first sight.  Look
> again, it's not.  You have one struct with both config info and state
> info mixed in there.  It's not clear who has to setup stuff:  It is the
> dvb adapter driver or is it the frontend driver?  Same for releasing the
> stuff.
>  
mmh... we could seperate state and config/setup variables into two 
seperate structs, then the config pointer will point to some readonly 
memory in the card driver code and the state struct pointer shows to the 
actual state variables. May be easier to understand.

> I have both separated.  That makes it possible to have static allocated,
> read/only config data structs.  And it's also pretty clear who has to
> maintain what:  The dvb adapter driver's job is to care about the config
> data, and it is the frontend drivers job to maintain its own state info.
> It is next to impossible to get it wrong.  And that is a big advantage
> in code maintainability.
>
> Maybe that isn't a big problem now when writing the stuff new from
> scratch and know exactly how you have designed it.  But it is a problem
> if someone else looks at the code or even if you look at it yourself
> again one year later.
>  
I don't really get your point. The kernel-i2c code was the one that 
again and again caused problems because developers didn't understood the 
API right: even today we have a mail in the mailing list archive 
regarding this. Go back in your inbox and you'll find similiar ones 
every few weeks.

Holger