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

Yeasah Pell yeasah at schwide.com
Tue Jun 13 23:42:07 CEST 2006

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.

More information about the linux-dvb mailing list