Re: [PATCH] drivers: staging: lustre: lustre: include: add "__attribute__((packed))"for the related union

[Chen Gang]

On 02/03/2014 06:03 PM, Chen Gang wrote:
> On 02/03/2014 04:58 PM, Dan Carpenter wrote:
>> On Sat, Feb 01, 2014 at 09:57:39PM +0800, Chen Gang wrote:
>>> It seems, our kernel still stick to treate 'pack' region have effect
>>> with both 'align' and 'sizeof'.
>>>
>>
>> It's not about packed regions.  It's about unions.  It's saying the
>> sizeof() a union is a multiple of 4 unless it's packed.
>>
>> union foo {
>> 	short x;
>> 	short y;
>> };
>>
>> The author intended the sizeof(union foo) to be 2 but on metag arch then
>> it is 4.
>>
> 
> Yeah, just like your original discussion.  :-)
> 
> 
> Hmm... can we say: "for metag compiler, in a pack region, it considers
> variables alignment, but does not consider about struct/union alignment
> (except append packed to each related struct/union)".
> 
> For compatible (consider about its ABI), it has to keep this features,
> but for kernel, it needs be changed.
> 
> So, I suggest to add one parameter to compiler to switch this feature,
> and append this parameter to KBUILD_CFLAGS in "arch/metag/Makefile"
> which can satisfy both ABI and kernel.
> 

After append the parameter to KBUILD_CFLAGS in "arch/metag/Makefile",

 - I guess/assume "include/uapi/*" should/will not need be modified.

 - but need check all files in "arch/metag/include/uapi/*".
   (add padding data for packed struct/union when __KERNEL__ defined)

 - maybe we have to process metag related ABI which not in "*/uapi/*"
   (add padding data for packed struct/union when __KERNEL__ defined)
   and when we find them, recommend to move all of them to "*/uapi/*".


Sorry, I don't know whether this way is the best way or not, but for me
it is an executable way to solve this feature issue and satisfy both
kernel and ABI.


Thanks.
-- 
Chen Gang

Open, share and attitude like air, water and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/