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

Yeasah Pell yeasah at schwide.com
Tue Jun 13 23:03:53 CEST 2006


Manu Abraham wrote:

> Yeasah Pell wrote:
>
>> Manu Abraham wrote:
>>
>>> Alan Nisota wrote:
>>>
>>>> On 6/12/06, Johannes Stezenbach wrote:
>>>>
>>>>> On Sun, Jun 11, 2006, Alan Nisota wrote:
>>>>>
>>>>>> Well, as it didn't seem that S2 was going anywhere, I had lost track
>>>>>> of this conversation a month or so ago, but now that I had to do 
>>>>>> some
>>>>>> mythtv work, I am trying to catch up.  I've looked over Manu's 
>>>>>> patch,
>>>>>> and associated sample app, and I don't think I really understand how
>>>>>> this method is supposed to work.
>>>>>
>>>>>
>>>> While I was looking at the ver7 patch when I wrote that mail, I have
>>>> since looked at the rev7a version as well, and I dhave questions.  I
>>>> understand how to use the new API, but am unsure what is expected from
>>>> an application perspective.
>>>> Specifically, if the API is version 3.2, does that mean that all cards
>>>> can be accessed with the new DVBFE ioctls (which would make things
>>>> relatively nice, as an app needs to support only one or the other as
>>>> defined at compile-time), or does each driver need to be ported to use
>>>> the new API, in which case there needs to be some way to designate
>>>> which cards support the new drivers?
>>>
>>>
>>>
>>> There are a couple of cases due to backwards compatibility etc.
>>>
>>> (1) make the API respond only to the new ioctl's
>>>
>>> The problem with this is that there are apps out there, that which 
>>> need some period of time to change over, asking them to switchover 
>>> to new IOCTL's would be rather very rude.
>>>
>>> (2) leave the old ioctl's and callbacks as it is
>>>
>>> In this case all existing apps that are working now will work 
>>> exactly the same way as it used to do earlier, the reason being 
>>> nothing changed as regards to the old convention.
>>>
>>> With regards to the new IOCTL's and calls there are now 2 different 
>>> ways.
>>>
>>> (a) Port all existing drivers to the new scheme
>>>
>>> This is not something that is very easy and cause drivers to break 
>>> down. We need some time to port the drivers
>>> moreover some of the existing drivers can get a facelift as well 
>>> while we are at it. So it is not a fast transition.
>>>
>>> (b) We add in the new callbacks as regards to the new drivers. The 
>>> old drivers can follow at a slower pace. this has the advantage that 
>>> all the features will be available for the new devices, but the 
>>> older ones have just the same old features only.
>>>
>>> IMHO, 2 (b) is something that can go ahead without breaking all 
>>> drivers/apps. The disadvantage of this scheme is that in any way, if 
>>> applications have to migrate to the newer calls, the drivers have to 
>>> be completed too.. but looking at another angle, the application 
>>> guys get another advantage from this that, they can implement this 
>>> interface once when one or two drivers are ready since they need to 
>>> test it as well. The advantage here is that the applications also do 
>>> get sufficient time to settle down. ie, it can go in a stable manner 
>>> without any breakages, hopefully. ie applications that have 
>>> completed the transition as well as the drivers that are written to 
>>> the case of the updated API will function, while the old ones can 
>>> still work as was running earlier itself.
>>
>>
>> Wouldn't it be possible to create a translation layer that proxies 
>> calls to old drivers from the new interface in the case of an 
>> application trying to use an old driver via the new API? 
>
>
> I did some stuff to fill in the fields from the old ioctl's (app 
> interface) to the new callbacks (at the driver side) I had a small 
> discussion.
>
> The details are like this, in this case we have to manually copy 
> everything in dvb_frontend
>
> (1) This looks ugly inside dvb_frontend
> (2) Backward compatibility needs to be tested, just like the new API 
> as well
> (3) We have to modify the drivers as well.
>
>> This would make the transition much nicer for app developers, since 
>> there wouldn't be any need to query and support two different APIs at 
>> once. I had assumed this was part of the transition plan, since it 
>> seems conceptually easy at a high level, but maybe there's something 
>> in the new API that would make this difficult.
>
>
> Alongwith the new API change what we thought was , eventually we will 
> add tuning algorithms too for better tuning.
> but if we are to follow backward compatibility by "backfilling" this 
> would eventually be a mess in most cases.
>
> The next aspect is that, the time needed to get this going and tested, 
> we can utilize this for other useful things, which lie ahead.
>
>> My idea of what would happen is at some point the multiprotocol API 
>> would be finalized for general use, and the old API would at that 
>> point be fully deprecated and optional, present strictly for the 
>> benefit of apps that had not yet been updated to work with the new 
>> API. Otherwise apps will have to detect at runtime which API to use, 
>> possibly using both APIs at once if the user has cards of both old an 
>> new type. That sucks.
>>
>
> What i mean to say, if we leave it as it is, there will be 
> compatibility from all sides, and a transition is easier for all.
> ie the apps can use the old ioctls (for the apps that haven't yet 
> changed) and the apps that have changed they can use the new ioctl's, 
> but the apps will be able to use them for the drivers that which have 
> changed. This way the transition would be gradual.
>
> But if you mean to say that new apps should use the new callback's, 
> that is also possible as it is just duplicating some code in the 
> driver as for fe_get/set_frontend for fe_set/get_params, (search and 
> track are completely different from this perspective) till the 
> transition period. What i was trying to avoid was the code duplication 
> at any point of time and unnecessary work.
>
> The biggest advantage is in this, is that backward compatibility need 
> not be tested, since we don't change anything.
>
>
> Manu
>
>
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);

Which would be a fair bit of (trivial, mindless) typing, but could be 
stuck off in its own dvb_frontend_compat.c file. Once you had these 
functions, you could arbitrarily translate requests back and forth, e.g.:

DVBFE_GET_DELSYS -> FE_GET_INFO
DVBFE_SET_PARAMS -> FE_SET_FRONTEND
DVBFE_GET_PARAMS -> FE_GET_FRONTEND
DVBFE_GET_INFO -> FE_GET_INFO

If we did this today, applications could *immediately* start using the 
new API (admittedly, without any of the new goodies) -- applications 
would be less complex (no need to detect and use the right API at 
runtime), and all the drivers with old callbacks would work through both 
the old and new API with absolutely no modification. You might even be 
able to use it to present a reduced subset of a new-callback driver 
through the old API (i.e. you could present the DVB-S half of a DVB-S2 
card through the old API)

I don't see this as a big effort (again, yes a bunch of typing, but very 
trivial stuff) in the short term, i.e. when we really need it, during 
the transition period. Once 100% of the drivers are updated to be native 
to the new callbacks, the whole thing could be chucked out, so it 
shouldn't be much of a maintenance issue. Or maybe one would decide that 
maintaining the compatibility layer is easier than upgrading all the old 
drivers, I dunno.

I think it might be worth it, if only to get apps using the new API as 
soon as possible. But I may be missing something.




More information about the linux-dvb mailing list