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