[linux-dvb] Re: refactoring

[Ralph Metzler <rjkm@metzlerbros.de>]

Holger Waechtler writes:
 > >Holger Waechtler writes:
 > You should try to encapsulate them at lease so that porting is made 
 > easy. You know that there have been several approaches in the past to 

No, encapsulation adds unnecessary overhead which I do not need.

 > port the linux-dvb code to BSD, MacOS-X and even the GPL'd Windows BDA 
 > drivers on sourceforge mention the linux driver as codebase:
 > 
 > http://cvs.sourceforge.net/viewcvs.py/bdadev/NovaTDriver/saa7146.cpp?rev=1.11&view=auto

So?

 > btw: the BDA drivers are a very nice example how to encapsulate your 
 > code away from OS-specific APIs: please take a look on the l64781 or 
 > SAA7146 implementations, they are much better organized, simpler and 
 > easier to maintain that their linux parents:

No, they just use a different API. Maintaining a driver just for
the Linux API is the same work. 


 > I think it's a good thing to inherit some of the ideas and maybe we even 
 > reach one day a point where a common 'hardware library' codebase can 
 > used for all platforms and the OS-specific PCI/USB/BDA/linux-DVB API 
 > registration functions are collected in a single file as small and 
 > compact as possible.

This almost always adds extra overhead, be it in shape of extra
API wrappers or at least lots of "glue-defines".
I do not care if porting to other OSs is easy, especially if it 
means extra unnecessary work and if I just want to write a Linux driver.
Other OSs can alwas write wrappers which emulate Linux APIs if they
want to use Linux drivers.

Yes, you can add abstraction layers which may even make a driver 
more resistant to internal changes in Linux and also support other
OSs at the same time. But you will always have to add extra wrapper
APIs and have to make compromises in the wrapper code which do not 
let you use all specific features of the underlying OS. 

And is this "linux-dvb" or "allOSs-dvb"?

 
 > > > Not allocating dynamic memory but using static data 
 > > > instead is always a good thing.
 > >
 > >Why?
 > >Now each and every driver has to take care of it instead of just the
 > >demodulator driver.
 > >  
 > >
 > 
 > no. Please have a look:
 > 
 > struct budget_with_stv0299 {
 >     struct pci_device pcidev;
 >     struct dma_related_stuff dma;
 >     struct stv0299_state_and_config stv0299;
 >     /* ans so on... */
 > };
 > 
 > this card struct gets allocated once in the pci attach() can and freed 
 > in the release() callback. No need for additional maintenance, kmalloc() 
 > and kfree() anywhere.

Yes, but it has to be put into the card driver config for each kind of
possible frontend. Currently, the frontend driver handles it itself,
depending on which frontend is found.


Ralph