[linux-dvb] [PATCH] Multi protocol support (stage #1)

Manu Abraham abraham.manu at gmail.com
Tue Jun 13 23:27:16 CEST 2006

Yeasah Pell wrote:
> Hmm. I dunno, I see the argument both ways.
> Well, we've got a situation where we have a collection of 'n' drivers, 
> 'm' applications, and 2 APIs. API #1 (the older API) has a certain set 
> of functionality, and API #2 (the multistandard API) is a proper 
> superset of this functionality -- it includes everything the first API 
> had, plus has significant additional flexibility to allow the 
> multistandard stuff, etc.
> As far as I can tell from looking at multiproto7.diff, right now it'd 
> be a straight mapping of stuff for the API. Assume for a minute you 
> have access to the following set of conversion functions:
> int to_old_params(const struct dvbfe_params* new_p, struct 
> dvb_frontend_parameters* old_p);
> int to_new_params(const struct dvb_frontend_parameters* old_p, struct 
> dvbfe_params* new_p);
> int to_old_info(const struct dvbfe_info* new_p, struct 
> dvb_frontend_info* old_p);
> int to_new_info(const struct dvb_frontend_info* old_p, struct 
> dvbfe_info* new_p);
> int delsys_to_caps(enum dvbfe_delsys new_p, fe_caps_t* old_p);
> int caps_to_delsys(fe_caps_t old_p, enum dvbfe_delsys new_p);

Having bidirectional compatibility will cause people to be stuck with 
the compatibility layer itself, rather than to use the new API, which 
will be just another half baked approach. Anyway there should be ideally 
compatibility in one direction only as we decided to move eventually.(ie 
compatibility to applications)

It will be nice to have this featureset (ie, bidirectional 
compatibility), but will need to handle swzigzag and inversion handling 
etc. IMHO, this will be a bit too much duplication inside dvb_frontend.


More information about the linux-dvb mailing list