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.
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
