Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Oct 2002 12:30:48 +0300
From:      Maxim Sobolev <sobomax@FreeBSD.ORG>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Robert Watson <rwatson@FreeBSD.ORG>, "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:  <20021016093048.GB10908@vega.vega.com>
In-Reply-To: <3DAD2B79.AD5412CA@mindspring.com>
References:  <Pine.NEB.3.96L.1021016004135.36711H-100000@fledge.watson.org> <3DAD2B79.AD5412CA@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 16, 2002 at 02:03:53AM -0700, Terry Lambert wrote:
> Robert Watson wrote:
> > While I think support for the IPC_64 flag under emulation is useful, I'd
> > rather make use of compatibility system calls and type improvements for
> > the base FreeBSD implementation of the System V IPC APIs.  Most of the
> > work necessary to support those changes is required in order to better
> > support fine-grained locking and MAC (breaking out the user and kernel
> > structures).  Also, it means future applications will make use of the
> > improved APIs by default.  In addition, other systems, such as Solaris,
> > have already made this change in this way, avoiding the IPC_64 flag
> > design.
> 
> You could also simply use non-intersecting cmd parameter values
> for the new calls, which avaids the special flag, and leaves the
> backward compatability without adding grundles of new system calls.

What about source-level compatibility, which IMO is a good thing,
at least if it doesn't add too much complexity (it clearly doesn't
in this case)? Also, handling single flag should be easier from
the coding perspective than a load of new values, after all
we can do something like:

#define	IPC_STAT_OLD	0xXY
#define	IPC_SET_OLD	0xZW
[...]

#define	IPC_64		0x100

#define	IPC_STAT	(IPC_STAT_OLD | IPC_64)
#define	IPC_SET		(IPC_SET_OLD | IPC_64)
[...]

Which automagically will bring 64-version of syscalls after
recompilation, while retaining ABI compatibility.

-Maxim

> I thought that everything was going to 64 bits and we were getting
> a new system call entry vector in 5.x, anyway... wasn't Matt going
> to do something like that?
> 
> -- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021016093048.GB10908>