On Tuesday 18 April 2006 19:27, Alan Nisota wrote:
> 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.
that is right actually.
i'll think about it to clearify the advantages for myself.
> > 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)
you will get the messages just at compile time. and of course if you have e.g.
-Werror within your c/c++ compiler flags, compilation will fail due to errors.
> > 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.
yes, that is true i your way of thinking. but, if you think a bit more, just this behaviour is
rising up all the problems we have, isn't it?
following is just my personal opinion:
"having api specific code at some small codepieces wouldn't bring up these _huge_ patches or
your mentioned #ifdef #else #endif orgies for them.
everybody should be free in his way to implement things, but also has to take the results, if they
lead in much work."
best regards
marcel
ps. if my answer comes up in a "rough" way, don't take it too serious. i am working on different
proposals for nearly 2 month now. everytime i think that we get a solution we can go for,
someone comes up with another way of thinking :) i don't mind and keep on working until
it is done. thanks for your participation alan.
Attachment:
pgpLj3M1Aa9Gk.pgp
Description: PGP signature
_______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
