Date: Wed, 16 Oct 2002 11:44:41 -0400 (EDT) From: Christopher Allen Wing <wingc@engin.umich.edu> To: freebsd-arch@freebsd.org Subject: why IPC_64 (Re: short uid/gid) Message-ID: <Pine.LNX.4.44.0210161039350.15065-100000@pi.engin.umich.edu>
next in thread | raw e-mail | index | archive | help
Hello,
I was the person responsible for IPC_64 in Linux. Let me summarize what
happened so that you get the history behind this.
IPC_64 is basically intended as a kernel-libc private interface. It is not
exposed to user-side applications through the standard include files. At
the time that the kernel changes were made, the Linux kernel hackers
preferred the IPC_64 modifier flag to a new system call entry point.
The kernel changes included new system calls for 32-bit uid/gid,
including:
{,l,f}stat()
{,l,f}chown()
{get,set}{,e,re,res}{uid,gid}()
In addition to the kernel changes, the user-side SysV IPC structure
definitions were decoupled from the kernel's definitions. glibc in Linux
wraps the IPC system call, and handles all the backward compatibility
issues.
Starting with glibc 2.2, glibc's headers (which are what user-side
compiles include) contain a new definition of the SysV IPC structures with
32-bit UIDs, 64-bit sizes for shared memory, increased message queue
limits, etc.
Binary compatibility with old applications is handled by 'versioned
symbols'. If you compile a program that uses SysV IPC against a newer
glibc, you get symbol references that look like this:
linux-glibc22% nm ./ipcs |grep ctl
U msgctl@@GLIBC_2.2
U semctl@@GLIBC_2.2
U shmctl@@GLIBC_2.2
Programs built against older versions of glibc will have older symbol
references:
linux-glibc21% nm ./ipcs |grep ctl
U msgctl@@GLIBC_2.0
U semctl@@GLIBC_2.0
U shmctl@@GLIBC_2.0
The older symbols use the older structure definitions. glibc 2.2 and above
contains both sets of symbols.
User-side compiles do not specify IPC_64. They just get the newer
structure definitions when compiled against glibc 2.2+ because we changed
the include files.
glibc handles backward compatibility when running on an older kernel. If
the kernel doesn't support IPC_64, glibc emulates it by translating the
older structure definitions to and from the new ones.
The upshot of this is that FreeBSD doesn't have to implement IPC_64 for
Linux programs to work under emulation. (although glibc will fall back to
using the older, 16-bit uid system calls)
The FreeBSD Linux emulator should implement IPC_64, and the other 32-bit
UID Linux system calls, for full functionality with newer Linux software.
The padding in the structures was an attempt to leave room for future
changes without creating a new version of the IPC system call. For
instance, you can see the padding for future 64-bit time. In retrospect, I
don't particularly like this decision. My gut feeling is that we are going
to end up needing another version of the IPC call anyway.
The extra padding shouldn't be a performance problem though, since the
structures with padding are only used for setting and examining
permissions on IPC objects, which I would expect to happen infrequently.
Regards,
Chris Wing
wingc@engin.umich.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.44.0210161039350.15065-100000>