[linux-dvb] [PATCH-REWORKED] frontend.h add dvb-s2 support including backwards compability

Johannes Stezenbach js at linuxtv.org
Fri Feb 24 16:25:34 CET 2006


On Fri, Feb 24, 2006, Felix Domke wrote:
> Johannes Stezenbach wrote:
> > On Wed, Feb 22, 2006, Marcel Siegert wrote:
> >>once again same topic.
> >>after short discussion with felix domke on irc, 
> >>we found that the attached solution is more suitable.
> > I'd actually prefer an extended definition of struct dvb_frontend_parameters
> > with room for more parameters (e.g. to query DVB-T cell ids etc.), plus
> > some padding to allow for future extensions.
> > FE_SET_FRONTEND would be redefined to use the new struct, however
> > it must be source code compatible (i.e. no changes to apps
> > necessary, they should continue to work with identical capabilites
> > if compiled against the new frontend.h).
> > Binary compatibility can be retained by adding *_OLD cruft,
> > see dvb/net.h for an example.
> > What do you think?
> This would basicly be Marcel's first idea, right?

Except that there'd no _EX stuff but apps would get
the new definitions automatically (provided it could
be done without breaking source compatibility, I haven't
taken the time to think this through to the end).

> Now, the basic idea was to let FE_SET_FRONTEND(_EX) operate not on a
> full dvb_frontend_parameters, but on a subset, i.e.
> sizeof(frequency)+sizeof(inversion)+sizeof(struct dvb_<mode>_paramters).
> That would make it possible to define new fields, without breaking old
> applications.
...
> Now, we could simply add a field into the "struct
> dvb_frontend_parameters", say:
> 
> struct dvb_frontend_parameters_ex {
> 	int standard; /* new */
>  	__u32 frequency;
> 	fe_spectral_inversion_t inversion;
>  	union {
> 		struct dvb_dvbs_parameters qpsk;
> 		struct dvb_dvbc_parameters  qam;
> 		struct dvb_dvbt_parameters ofdm;
> 		struct dvb_dvbs2_parameters qpsk2;
> 		...
>  	} u;
>  };
> 
> Note that the size of this struct can grow when new standards are added.
> All kernel stuff only uses the actually used structure, which is
> indicated by the "standard"-field.

dvb_usercopy() and the fact that ioctl numbers encode the
size of the parameter struct complicate this, but I guess
it could be done somehow.

If we would add *_ex stuff, why not go all the way:

struct dvb_frontend_parameters_ex {
	int standard;
	__u32 frequency;
	fe_spectral_inversion_t inversion;
	void *mod_params;
	__u32 mod_params_size;
};

Then one could add new standards without problems, and
one could add new fields to exisiting standards.

> Now, as small modification to the above, i would introduce the
> FE_SET_MODE (i would call it FE_SET_STANDARD), in order to replace the
> "standard" field in the structure.
> 
> That would have a number of advantages:
>  - We could keep the available IOCTLs. FE_SET_MODE set the required
> mode, and FE_GET_FRONTEND etc. are 100% backward compatible when an
> "old" standard is selected.
>  - There is no special need to specify the FE_GET_FRONTEND/FE_GET_EVENT
> behaviour. The whole frontend operates on the standard set by the
> FE_SET_MODE ioctl.
>  - Capabilities (for example, the symbol rate range, which typically
> differs between DVB-S and DVB-S2) could change after a FE_SET_MODE
>  - Combo frontends, for example DVB-S/DVB-T, could be handled fine. You
> just switch them to the required standard.

This sounds good.

> Some notes to backward compatibility:
> 
> An application not prepared for a new standard would never select a
> standard which doesn't fit into their idea of the union size. Thus this
> would give backward compatibility (older apps with newer core).
> 
> Newer applications, selecting a standard which isn't available, would
> detect that this standard is not available (FE_SET_MODE would fail).
> This is also no problem.
> 
> Newer applications, running with an older dvb-core which doesn't know of
> FE_SET_MODE would allocate the current size of the union. The older
> dvb-core would copy sizeof(dvb_frontend_parameters), not the specialized
> number of bytes (which could be less). This is also no problem - an
> application should always use the "struct dvb_frontend_parameters".

Sound good, too. Can it be implemented without too much ugliness?


Johannes



More information about the linux-dvb mailing list