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
> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Date: Fri, 22 Sep 2000 20:26:13 +0200
> Cc: libc-alpha@sources.redhat.com
>
> On Fri, 22 Sep 2000, Geoff Keating wrote:
> > > 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.
>
> Hmm, I thought backwards compatibility is maintained with versioning and
> ipc_priv.h containing:
>
> struct __old_ipc_perm
> {
> __key_t __key; /* Key. */
> unsigned int uid; /* Owner's user ID. */
> unsigned int gid; /* Owner's group ID. */
> unsigned int cuid; /* Creator's user ID. */
> unsigned int cgid; /* Creator's group ID. */
> unsigned int mode; /* Read/write permission. */
> unsigned short int __seq; /* Sequence number. */
> };
>
> ?
> I don't want to change __old_ipc_perm, I want to know if changing seq to an
> 'unsigned long' (which is what 2.4 has on all platforms) in ipc_perm is safe
> and I can't think of a reason why this wouldn't work with proper
> versioning.
I don't understand. I was talking about the kernel <-> libc
interface, and you started talking about versioning which is the
libc <-> application interface. Which one do you want to change?
(Hint: you cannot change the kernel <-> libc interface unless
the kernel uses a different syscall number or something, and you
cannot change the libc <-> application interface unless you use
symbol versioning.)
--
- Geoffrey Keating <geoffk@cygnus.com>