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