Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: refactoring



On Sunday 10 Oct 2004 15:45, Gerd Knorr wrote:
> > Before anyone gets too excited, this was an experimental structure. I
> > think a better solution would be something like:
> >
> > struct dvb_fe {
> >  struct fe_api  *api;
> >  struct dvb_adapter *dvb;
> >  void            *priv;
> > };
> >
> > struct fe_api {
> >  struct dvb_frontend_info info;
> >
> >  void (*attach)(....)
> >  void (*set_tps)(struct dvb_fe*, struct dvb_frontend_parameters*);
> >  void (*get_tps)(struct dvb_fe*, struct dvb_frontend_parameters*);
> >  void (*get_status)(struct dvb_fe*, struct fe_status*);
> >  /* whatever else is needed, for diseqc, ... */
> >  void (*destroy)(struct dvb_fe*);
> > };
>
> Looks ok.  What attach() should do?

Bug - I was experimenting with moving attach into there at that time. I've 
decided its a bad idea.

> > fe_api then allows the card driver to override the functions as
> > necessary, and also to tailor the dvb_frontend_info structure to be
> > suited to its exact hardware.
>
> I'd expect the fe drivers have fe_api statically allocated (maybe
> multiple versions for different hardware) and then just put a pointer
> to it into the dynamically allocated dvb_fe.  Thats an minor
> implementation detail through, of course you'll can allocate it
> dynamically as well, the driver just as to take care to release it in
> the destroy callback then ;)

Exactly what I'm thinking. For example dvb_dummy_fe now just defines three 
separate static structures, one for each frontend type. 

If you don't need to override the function pointers, you can just supply the 
static one - otherwise you memcpy it and muck about with it to your heart's 
content.




Home | Main Index | Thread Index