Re: [PATCH] Add ipc.h for aarch64

[Alan Hayward <alan dot hayward at arm dot com>]

On 21/10/2014 12:01, "Alan Hayward" <alan.hayward@arm.com> wrote:

>
>On 21/10/2014 11:31, "Christoph Hellwig" <hch@lst.de> wrote:
>
>>On Tue, Oct 21, 2014 at 10:52:44AM +0100, Marcus Shawcroft wrote:
>>> On 21 October 2014 09:35, Alan Hayward <alan.hayward@arm.com> wrote:
>>> > Copied sysdeps/unix/sysv/linux/mips/bits/ipc.h to (new file)
>>> 
>>> We are currently using sysdeps/unix/sysv/linux/bits/ipc.h, I'd prefer
>>> we took a copy of that file and changed:
>>> 
>>> unsigned short int mode;            /* Read/write permission.  */
>>> unsigned short int __pad1;
>>> ->
>>> unsigned int mode;            /* Read/write permission.  */
>>> 
>>> Rather than take the other changes present in the mips file.
>>
>>Given that Marcus mentioned that all 64-bit BE Linux targets want
>>a 32-bit mode field, how about making a change to
>>sysdeps/unix/sysv/linux/bits/ipc.h so that it can be used as-is for all
>>these targets?
>
>I did initially think about this, but each architecture seemed to have
>subtly different version of the file, even though I think ultimately they
>all end up with the same shaped structure. Also, I was shying away from
>making a change where I was actively changing many different targets.
>
>I can take a look into creating a unified version.
>

Ok, looking into this a little further:

Power, ia64
*Has own file with __mode_t mode.

Hppa, sparc, s390
*Has own file. If 32bits, Short int mode else __mode_t mode

Mips, alpha
*Has own file with int mode.
*Also, additional fields use unsigned int instead of _uid_t/_gid_t etc


i386/x86_64/x86, arm, m68k, anything else:
*Use default file. Unsigned short int mode



Which breaks down to: 32bit targets use short int, 64bit targets use int.
Expect for the odd case out of x86_64, which always uses short int.

I think therefore we should probably:
1) Add a #if __WORDSIZE == 32 check into the generic ipc.h
2) Remove all specific ipc.h files
3) Add a specific x86_64 version for the odd case out

However, I would like to delay that change to a future patch, as it has
the potential to break in ways I might not immediately catch.

For this patch I would just make the changes Marcus suggested.

Does that make sense?


Alan.