Manu Abraham wrote:
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
Yeah, I agree that bidirectional support is probably too much, anything
that can be done to discourage the future use of the old API is welcome
:-) I only specified bidirectional conversion because the structures
would need to be converted both ways (i.e. params is used as an in for
tuning, as well as an out for status), my comment about using it to
support bidirectional API conversion was off-the-cuff and not very well
thought out.
Really all I'm trying to suggest is that once the new API is made
available, every card should be accessible through it. If that means
having a translation layer in the short term (i.e. until all the drivers
are updated), I think it might be a good idea -- unless of course it's
going to be almost as much work as just updating all the old drivers, in
which case it makes more sense to just do that. But I'm not really fond
of the idea of a lengthy period of time wherein drivers slowly migrate
from the old API to the new one.
I think having the new API be fully capable will speed its adoption by
application developers, and I'm thinking it adds more benefit (when you
think about the linux DVB system as a whole, including the API, the
drivers and the applications) than it costs.
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
