Date: Wed, 16 Oct 2002 12:07:16 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: Terry Lambert <tlambert2@mindspring.com>, "Danny J. Zerkel" <dzerkel@columbus.rr.com>, "Vladimir B. Grebenschikov,Moscow,408-7227,123-4567,Some-info" <vova@express.ru>, freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: short uid/gid Message-ID: <Pine.NEB.3.96L.1021016113538.24763A-100000@fledge.watson.org> In-Reply-To: <3DAD8084.C60C5C0F@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Oct 2002, Maxim Sobolev wrote:
> > And it's not like the approach you've described makes it any easier to
> > implement: you still have to break out the old and new structures since
> > changing ipc_perm breaks the ABI for all of the System V interfaces,
> > rewrite the kernel code, etc. You might as well have added the
> > compatibility system calls since you still have to do all the mapping.
>
> I don't quite understand what you are trying to say. Linux does the
> following on the beginning and the end of each {shm,sem,msg}ctl call:
>
> {shm,sem,msg}ctl(...)
> {
> if (IPC_64 flag is not set) {
> convert user-supplied structure to a new 64-bit format
> }
> proceed as usual using 64-bit structure
> if (IPC_64 flag is not set) {
> convert result to be transferred back to user into old format
> }
> return
> }
>
> This is apparently much more compact, ABI-safe and easier to implement
> and maintain since we don't have two versions of mostly the same code.
What you are missing here is that the same structures used in kernel are
used in userspace, so an important step to "fixing" the SysVIPC problem is
to divorce those structures, which means you need two sets of internalize
and externalize functions. Your proposed solution involves exactly as
much code as the other solution, it just happens to do the compatibility
above the system call layer rather than at the system call layer.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
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.NEB.3.96L.1021016113538.24763A-100000>