[linux-dvb] [PATCH] add DVB-S2 support to frontend.h

Johannes Stezenbach js at linuxtv.org
Sun Mar 5 15:25:07 CET 2006

On Thu, Mar 02, 2006, Rainer.scherg wrote:
> Johannes Stezenbach schrieb:
> >1. 	ioctl(FE_GET_VERSION);
> >	if (api_version_minor > 1)
> >		/* assume FE_SET_STANDARD is available */
> >
> >2.	ioctl(FE_GET_CAPS);
> >	if (caps & FE_CAP_SET_STANDARD)
> >		/* we know FE_SET_STANDARD is available */
> >
> >My personal preference is 2.
> "2." will work as long as there is no need to change
> any data structures. Best example here is the switch from
> DVB API v1 to v3.

v1 API was considered unstable/beta, i.e. is was deemed acceptable
to make incompatible changes. VDR was about the only user at
the time, so while it wasn't nice for the vdr guys to deal
with, I think it was the right decision.

> Enabling an application to check the api version at runtime
> has 3 advantages:
>   - application can do stop smoothly before crashing due
>     to wrong data structures

That must never happen. We guarantee backwards compatibility,
even at the expense that the API gets uglier.

>   - application can do a fallback

They can do it without GET_VERSION.

>   - no effort to implement (no one gets hurt here)

Simple to implement in dvb-core, hard for all application
and library authors to deal with. They are the ones
who get hurt.

> Also a word about what we discussed on IRC:
> IMO we should take the chan[g|c]e to design a new dvb api here
> e.g. "skip" v4 and start v4.1 or v5).
> A "frozen" api v3 compatibility  layer should be provided for
> the new api, so older/current applications can be run without
> redesign or code changes.
> The new api doesn't need to follow api v3 (or v4) structures
> (e.g. better use pointers instead of unions in some data
> structures to get more flexibility to enhancements, etc.).

Sounds good ;-), but is independent of the current task
of adding DVB-S2 support with as little fuss as possible.


More information about the linux-dvb mailing list