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
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
