[linux-dvb] [PATCH] Multi protocol support (stage #1)
abraham.manu at gmail.com
Wed Jun 14 00:07:31 CEST 2006
Yeasah Pell wrote:
> Manu Abraham wrote:
>> Yeasah Pell wrote:
>>> 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);
>> Having bidirectional compatibility will cause people to be stuck with
>> the compatibility layer itself, rather than to use the new API, which
>> will be just another half baked approach. Anyway there should be
>> ideally compatibility in one direction only as we decided to move
>> eventually.(ie compatibility to applications)
>> It will be nice to have this featureset (ie, bidirectional
>> compatibility), but will need to handle swzigzag and inversion
>> handling etc. IMHO, this will be a bit too much duplication inside
> Yeah, I agree that bidirectional support is probably too much,
> anything that can be done to discourage the future use of the old API
> is welcome :-) I only specified bidirectional conversion because the
> structures would need to be converted both ways (i.e. params is used
> as an in for tuning, as well as an out for status), my comment about
> using it to support bidirectional API conversion was off-the-cuff and
> not very well thought out.
> 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.
> 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.
> I think having the new API be fully capable will speed its adoption by
> application developers, and I'm thinking it adds more benefit (when
> you think about the linux DVB system as a whole, including the API,
> the drivers and the applications) than it costs.
More information about the linux-dvb