Re: struct ipc_perm and size of seq member

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

At 06:26 25.09.00, Geoff Keating wrote:
> > 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.)

The kernel doesn't use a new syscall number, but _IPC_64 is or'ed into the 
'cmd' parameter to mark the "version" of the structure. And yes both the 
user<->libc and libc<->kernel interfaces have to match. Look at my other 
post with a kernel and a glibc patch, which I think basically does the 
right thing. I'm still unclear about ipc_perm.seq though:

- kern_ipc_perm.seq is 'unsigned long' internally in linux-2.4 
(linux/include/linux/ipc.h)
- all other archs limit it in kernel space to 'unsigned short' in their 
target specific ipc64_perm (linux/include/asm-*/ipcbuf.h
- glibc defines the structure 1:1 to the kernel ipc64_perm in the target 
specific headers (which were missing for PPC, see the patch in the other post)

So why do the other archs limit seq to 16bit in the kernel? I can't see a 
reason for that. Since ipc64_perm is all-new, we should be able to pass a 
32bit seq to userspace, _unless_ there _are_ userspace issues with a 32bit seq.

Franz.

PS. Any news on the binutils/visibility stuff?