On Sun, May 21, 2006 at 03:59:50PM -0700, Trent Piepho wrote: > On Sun, 21 May 2006, Johannes Stezenbach wrote: > > In my version of the patch I only added DUMMY values to those > > enums which didn't have any other "natural" value for 1 << 31 > > (AUTO was normally assigned 1 << 31). > > Maybe for all the enums, the most natural value can be assigned to (1<<31) so > that there doesn't need to be a DUMMY? AUTO is an easy choice. When there is > no AUTO, and something like ON or IGNORE exist, then that could be used. Like I said, if an enum only has e.g. four values (like inversion), then there is no point adding DUMMY. It will never grow beyond those four values, so there will never be a compatibility problem with changed sizes. OTOH adding two new delivery systems would change the size of enum dvbfe_delsys from 8bit to 16bit on ARM. > > BTW, on variable-sized-enums architectures the problem > > is only that a future API extension must not cause the > > size of an enum to change (because this would break binary > > compatibility). Maybe I got carries away and added a > > DUMMY in a place where an extension can never happen... > > Isn't there a problem with the current API for ARM systems? They changed > their ABI, and the new ABI has variable-sized-enums and the old one didn't. Many ioctls use enums, e.g. lots of the v4l2 ones. No problem as long as kernel and userspace agree on the size of the ioctl arguments. Johannes _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
