On 4/18/06, Marcel Siegert <mws@xxxxxxxxxxx> wrote:
> On Sunday 16 April 2006 16:05, Alan Nisota wrote:
> what way should be preferred? breaking compatibility or stay at old api capabilities
> having no way support for dvb-s2.
> (ok, there's one way, but that would be an ugly solution also)
I know it's been gone over before, but why not just define
dvb_parameters_new as something like:
struct dvb_frontend_parameters_new {
__u32 frequency; /* (absolute) frequency in Hz for QAM/OFDM/ATSC */
/* intermediate frequency in kHz for QPSK */
fe_spectral_inversion_t inversion;
frontend_parameters_union u;
};
then....
typedef union {
struct dvb_dvbs_parameters qpsk;
struct dvb_dvbc_parameters qam;
struct dvb_dvbt_parameters ofdm;
struct dvb_atsc_parameters vsb;
struct dvb_dvbs2_parameters qpsk2;
struct dvb_private_paramters p;
} frontend_parameters_union;
struct {
__u32 private[64]; /* or whatever */
} dvb_private_paramters;
That would allocate a bunch of space in the structure for future
expansion while allowing for minimal effort from the app side to
support both the new and old API with only a few #ifdefs. Sure it
isn't pretty, but I would expect it would help adoption go a lot
smoother.
> marking something deprecated isn't the right solution all the time.
> but in this case it is signalling that there has been an api change/extension
> and old features/functions should be replaced by the developer. if i would not
> mark it deprecated, nobody will start to use the new ioctls. simply due to the fact,
> that nobody would maybe even get known of changes, except if they will support
> dvb-s2.
If something like the above was adopted (allowing the
dvb_parameters_new struct to be backwards compatible with
dvb_paramters) I wouldn't have a problem with this, as apps could
easily use either dvb_paramteres or dvb_paramters new depending on
kernel version with no other changes. But otherwise, you are also
adding warnings to the user's apps that he can't easily get rid of,
aren't you? (I haven't actually tried compiling yet, so I dunno if the
deprecated messages show up in user apps or not)
> normally i also do development on an application that uses e.g. dvb api v3, directfb, ect.
> maybe it is a matter of code design, that we don't have to patch a huge amount
> of source code. we organised it in a different way.
I don't think it is right to expect userspace apps to be designed in a
specific way, and we shouldn't cause them extra work unless there is
no other reasonable solution IMHO.
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
