This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: struct ipc_perm and size of seq member
- To: Franz dot Sirl-kernel at lauterbach dot com
- Subject: Re: struct ipc_perm and size of seq member
- From: Geoff Keating <geoffk at cygnus dot com>
- Date: Fri, 22 Sep 2000 10:18:08 -0700
- CC: libc-alpha at sources dot redhat dot com
- References: <5.0.0.19.2.20000922140442.01f72eb0@mail.lauterbach.com>
> Date: Fri, 22 Sep 2000 14:18:37 +0200
> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
>
> Hi,
>
> I'm finally able to run 2.4.0-t8 on my B&W G3 and can now track down the
> remaining problems with glibc-2.1.9x. With 2.4 I still have an IPC problem,
> that maybe related to different notion of the size of seq. 2.4 on PPC
> defines it as 'unsigned long', but glibc-2.1.94 uses it as 'unsigned
> short'. Besides the missing padding in powerpc/bits/ipc.h, why does glibc
> use a 16bit type here, while the kernel uses 32bit? Is this required for
> userspace compatibility?
This structure used to be
struct ipc_perm
{
__kernel_key_t key;
__kernel_uid_t uid;
__kernel_gid_t gid;
__kernel_uid_t cuid;
__kernel_gid_t cgid;
__kernel_mode_t mode;
unsigned short seq;
};
so the kernel change breaks backward compatibility, and the glibc
problem you're seeing is just one aspect of this.
Note that this structure has padding _after_ 'seq', not before.
'mode' is 4-byte aligned, being an int.
--
- Geoffrey Keating <geoffk@cygnus.com>