Hi Sakari, On Thursday 16 September 2010 17:36:29 Sakari Ailus wrote: > Laurent Pinchart wrote: > > On Monday 06 September 2010 18:51:59 Hans Verkuil wrote: > >> On Wednesday, September 01, 2010 16:05:10 Laurent Pinchart wrote: > >>> On Saturday 28 August 2010 13:02:22 Hans Verkuil wrote: > >>>> On Friday, August 20, 2010 17:29:09 Laurent Pinchart wrote: > ... > > >>>>> +}; > >>>> > >>>> Should this be a packed struct? > >>> > >>> Why ? :-) Packed struct are most useful when they need to match > >>> hardware structures or network protocols. Packing a structure can > >>> generate unaligned fields, which are bad performance-wise. > >> > >> I'm thinking about preventing a compat32 mess as we have for v4l. > >> > >> It is my understanding that the only way to prevent different struct > >> sizes between 32 and 64 bit is to use packed. > > > > I don't think that's correct. Different struct sizes between 32bit and > > 64bit are caused by variable-size fields, such as 'long' (32bit on 32bit > > architectures, 64bit on 64bit architectures). I might be wrong though. > > As far as I understand that's another reason for the structures not > being exactly the same. Alignment of different data types in structures > depends on ABI. I don't know the exact rules for all the architectures > Linux supports if there are cases where the alignment would be different > for 32-bit and 64-bit and smaller than the data type. On ARM there have > been different alignments depending on ABI (EABI vs. GNU ABI) which is > now practically history though. > > I couldn't find a better reference than this: > > <URL:http://developers.sun.com/solaris/articles/about_amd64_abi.html> > > 64-bit integers are aligned differently on 32-bit and 64-bit x86 but the > alignment is still smaller or equal to the size of the data type. Thanks for the link. > I'd also pack them to be sure. The structures should be constructed so > that the alignment is sane even if they are packed. In that case there's > no harm done by packing. It just prevents a failure (32-bit vs. 64-bit) > if there's a problem with the definition. Even if the structures were packed we would have a problem with media_user_links. The pads and links pointers will be 4-bytes long on 32-bit and 8-bytes long on 64-bit. There's no way around that. I could pad the structure to a fixed size with struct media_links_enum { __u32 entity; /* Should have enough room for pads elements */ struct media_pad_desc __user *pads; __u8 __pad1[8 - sizeof(void *)]; /* Should have enough room for links elements */ struct media_link_desc __user *links; __u8 __pad2[8 - sizeof(void *)]; __u32 reserved[4]; }; or with struct media_links_enum { __u32 entity; union { struct { /* Should have enough room for pads elements */ struct media_pad_desc __user *pads; /* Should have enough room for links elements */ struct media_link_desc __user *links; }; __u32 __pad[4]; }; __u32 reserved[4]; }; Is there any other way ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
