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

[Manu Abraham]

Yeasah Pell wrote:
> Manu Abraham wrote:
>
>> Yeasah Pell wrote:
>>
>>> 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.
>
>
> Ok, sorry about the confusion. I think I now see where I got lost in 
> your original response. If I'm now understanding you correctly, then I 
> would answer Alan's original question:
>
>> Alan Nisota wrote:
>>
>>> 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? 
>>
>
> With simply "all cards will be accessible through the new DVBFE 
> ioctls." Right?

Yes. Additionally the old one's would work exactly the same way, as it 
used to do, for a predefined period of time.

>>> 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.
>>
>
> Johannes? Even if things may not be perfect at this point, can we call 
> it good enough to move forward? It's been bounced about for a good 
> long time now, and I'm not sure how much better it will get without 
> actually getting some code into circulation.

Will need the "official signature" from Johannes though. :-)


Manu