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

Manu Abraham abraham.manu at gmail.com
Tue Jun 13 20:19:59 CEST 2006

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 

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.


More information about the linux-dvb mailing list