Re: [microblaze-uclinux] [PATCH 03/11] microblaze: fall back on generic header files for the ABI

[Arnd Bergmann]

On Wednesday 01 July 2009, Michal Simek wrote:
> I did this change because of problem with inconsistency between kernel/glibc.
> 
> Current our glibc ipc_perm struct - mode is short - that's why I have setup kernel_mode_t to short too.
> 
> /* Data structure used to pass permission information to IPC operations.  */
> struct ipc_perm
>   {
>     __key_t __key;                      /* Key.  */
>     __uid_t uid;                        /* Owner's user ID.  */
>     __gid_t gid;                        /* Owner's group ID.  */
>     __uid_t cuid;                       /* Creator's user ID.  */
>     __gid_t cgid;                       /* Creator's group ID.  */
>     unsigned short int mode;            /* Read/write permission.  */
>     unsigned short int __seq;           /* Sequence number.  */
>     unsigned short int __pad1;
>     unsigned long int __unused1;
>     unsigned long int __unused2;
>   };
> 
> Does it make more sense to define it as int?

It's more complex than this.

AFAICT, it does not matter at all whether you define it as 16 or 32 bits,
as long as it all fits together. For the generic ABI, I used 32 bits where
they were commonly used by some architectures, because there are processors
that can more efficiently access 32 bit words than 16 bit words.

One major reason for starting the asm-generic ABI definitions was to make
sure that all architectures that don't have their ABI set in stone can
use the exact same ABI, and if you change just a small thing, you would still
diverge from the common ABI.

Now the definition you give above matches neither the one from your current
kernel header nor the one from the asm-generic file, because of the location
of the padding. Worse, the __pad1 field actually causes implicit padding instead
of preventing it.

I think you should just update your glibc files to match the generic kernel
headers, because changing the ABI means that you have to change other parts
of glibc anyway and to recompile every single user space program anyway.
Doing one more change won't hurt that much either.

	Arnd <><
--
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/