Re: struct ipc_perm and size of seq member

[Geoff Keating <geoffk at cygnus dot com>]

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