For binary compatibility it isn't sufficient to just add new
fields to struct dvbs2_params. There must also be an indicator
which the kernel can use to see if struct dvb_frontend_params
was prepared by old or new userspace, i.e. if the new fields
are valid or contain uninitialized data.
That's why I propsed a "flags" field for struct dvbs2_params
in my version of the patch.
+/*
+ * DVB-S2 parameters
+ * ETSI EN 302 307, TR 102 376, EN 301 210
+ */
+struct dvbs2_params {
+ __u32 symbol_rate;
+ __u32 flags; /* for future use, must be 0 for
now */
+
+ enum dvb_fe_modulation modulation;
+ enum dvb_fe_fec fec;
+ enum dvb_fe_rolloff rolloff;
+ enum dvb_fe_stream_priority priority;
+};
And , what do these flags do ? I hope it is not a secret.
Currently nothing, as the comment says.
My understanding from watching this crazy debate is that the flags
identify extended content in the structure. At the time of API creation,
flags would always be zero, and padding would all be padding. As padding
gets converted into something useful in the future, userspace would set
bits in the flags variable to indicate the presence of valid data in the
former padding part of the structure. Users would be expected to set
"flags = DVBS2_PARAMS_FEATURE_1 | DVBS2_PARAMS_FEATURE_2" or something
like that if feature1 and feature2 were added in a later API and they
wanted to use those new fields.
Another way to do this that might be more familiar to some people (which
I am NOT advocating) is by not padding the structure at all, and instead
passing a structure length along with the structure from userspace (this
is a little easier for application developers since you just set
something to sizeof(struct xxx) instead of figuring out which bits to
set). Venerable old BSD sockets works this way for socket addresses, for
example -- there's a generic sockaddr structure which is relatively
small, and then there are extended sockaddr structures of different
lengths that define addresses for various domains (sockaddr_in,
sockaddr_unix, etc.) -- that case is a little different in spirit, since
it's designed primarily to deal with different socket address domains
instead of different versions of the structure, but it's the same
general idea: you avoid walking off the end of a changing user-supplied
structure simply by having the user pass a length.
The downside to this would be that you'd probably end up having to
maintain a bunch of different internal structures -- one for each
version that has ever been released -- and have some conversion function
for each structure type that converts the various incoming structures
into something the rest of the drivers understand. Plus the flags thing
has the added avantage of allowing you to make parameters optional if
you want -- a user could elect to not pass a particular parameter even
if they had the newest API just by not setting the flag.
Just trying to draw a parallel to the "flags-n-padding" based
backward-compatability system in the proposal to something that might be
more familiar to some people.
/y
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
