Mailing List archive

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

[linux-dvb] Re: refactoring



On Saturday 09 Oct 2004 10:10, Gerd Knorr wrote:
> > > Even a sane designed library will allocate and release the data
> > > structures itself and *not* ask the user of the library to do that.
> > > Data structures which are private (to the driver, to library or
> > > whatever you prefeare to call it) should be maintained by the owner and
> > > not someone else.  Not designing it this way is just insane and asking
> > > for trouble, please don't.
> >
> > You can find examples of exactly this approach all over the kernel.
> > Look at i2c_adapter for example - there are several fields defined in
> > there that should not be messed with by anything outside the i2c core.
> > Nothing is stopping you for mucking about with the list of clients
> > directly - but you'd be mad if you did.
>
> That it exists doesn't mean that it is a good idea.  Also i2c core isn't
> exactly a good example, it has various cruft in there for historical
> reasons.  Also note that the struct i2c_adapter is allocated + released
> by the i2c adapter drivers and _not_ by the i2c core.
>
> > This is pragmatism - hiding data is good I agree. However, there comes
> > a time when it is simply not worth the extra hassle.
>
> There is no extra hassle.  You have to allocate the data struct for fe
> _anyway_.  You'll just move that from the fe driver to the dvb adapter
> driver, which is simply the wrong place.
>
> IMHO the interface should look like that:
>
> struct dvb_fe {
>  fe_type_t       type;
>  struct fe_ops   *ops;
>  void            *priv;
> };
>
> struct fe_ops {
>  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*);
> };

Aha, we're starting to converge here. This is _very_ similar to the structure 
I prototyped for the function pointers a few days ago:

struct dvb_frontend_api {
        struct dvb_frontend_info info;
        struct dvb_adapter *dvb;
        void* vstate;

        int (*sleep)(void* vstate);
 .... other stuff
};

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*);
};

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.

Adding dvb_adapter to dvb_fe is purely for convenience - its not really 
necessary if people don't like it.




Home | Main Index | Thread Index