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