[linux-dvb] [PATCH] Multi protocol support (stage #1)
yeasah at schwide.com
Tue Jun 13 18:24:38 CEST 2006
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? 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
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.
More information about the linux-dvb