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

Manu Abraham abraham.manu at gmail.com
Wed Jun 14 00:07:31 CEST 2006


Yeasah Pell wrote:
> 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. 

Yes, it will be that way. I think the confusion came in because i 
mentioned the implementation of tuning algorithms, which need more time 
to be implemented.

Anyway, will keep that thing separate, since i found that to cause 
confusion as well.

> 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.

Regarding app. backward compatibility, we don't need a huge translation, 
i will post those changes soon. But yet needed to know whather the 
previous API changes were acceptable, waiting for JS's ACK on that.

> 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.

ACK


Manu




More information about the linux-dvb mailing list