Re: [xfs-masters] [PATCH] fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls

[Eric Sandeen <sandeen@sandeen.net>]

Boaz Harrosh wrote:
> Eric Sandeen wrote:
>> Boaz Harrosh wrote:
>>
>> ...
>>
>>> I don't understand
>>>
>>> if you have a structure like
>>> struct foo {
>>> 	u32 one;
>>> 	u32 two;
>>> };
>>> vs
>>> struct foo_packed {
>>> 	u32 one;
>>> 	u32 two;
>>> } __packed;
>>>
>>> Just adding an __attribute__((packed)) to it clearly does not change
>>> the layout of the structure. Are you saying the __attribute__((packed))
>>> is an hint to the compiler that foo_packed might be used unaligned. This
>>> is just brain-dead, because I can use an unaligned pointer to foo just as
>>> I can to foo_packed. Otherwise there is no difference what-so-ever between
>>> the two. I have to see it to believe. It is totally the wrong hint in the
>>> wrong place taking away valuable meaning of saying "please don't use padding
>>> holes in this structure"
>>>
>>> Sorry for been so slow, I just don't get it.
>>> Boaz
>> While I'm no gcc guru, I can confirm that gratuitous use of the packed
>> attribute is suboptimal; adding "packed" to every ondisk structure made
>> obdump -d xfs.ko | wc -l explode by about 15,000 lines on ia64.
> 
> Yes! but are the structures the same? that is sizeof(foo_packed) == sizeof(foo) ?
> If not then clearly above is expected.

Yes, they are the same.  They're disk structure definitions after all;
ia64 doesn't *need* the packing, but adding the packed attribute changes
the code that gcc generates.

See also, perhaps,
http://digitalvampire.org/blog/index.php/2006/07/31/why-you-shouldnt-use-__attribute__packed/

For an interface like this maybe it's fine, but sprnkling it around like
pixie dust may not be a good plan.  :)

-Eric