atom feed20 messages in org.freebsd.freebsd-archRe: short uid/gid
FromSent OnAttachments
Vladimir B. Grebenschikov,Moscow,408-7227,123-4567,Some-infoOct 14, 2002 12:33 am 
Robert WatsonOct 14, 2002 10:27 am 
Maxim SobolevOct 14, 2002 12:17 pm 
Danny J. ZerkelOct 15, 2002 7:47 pm 
Terry LambertOct 15, 2002 9:35 pm 
Robert WatsonOct 15, 2002 9:42 pm 
Terry LambertOct 16, 2002 2:03 am 
Maxim SobolevOct 16, 2002 2:30 am 
Robert WatsonOct 16, 2002 6:03 am 
Maxim SobolevOct 16, 2002 8:06 am 
Robert WatsonOct 16, 2002 9:06 am 
Terry LambertOct 16, 2002 9:29 am 
Terry LambertOct 16, 2002 9:45 am 
Robert WatsonOct 16, 2002 10:01 am 
Gary ThorpeOct 16, 2002 10:38 am 
Terry LambertOct 16, 2002 11:02 am 
Terry LambertOct 16, 2002 11:13 am 
Danny J. ZerkelOct 16, 2002 4:50 pm 
Danny J. ZerkelOct 16, 2002 8:44 pm 
Terry LambertOct 16, 2002 11:06 pm 
Subject:Re: short uid/gid
From:Maxim Sobolev (sobo@FreeBSD.ORG)
Date:Oct 16, 2002 2:30:26 am
List:org.freebsd.freebsd-arch

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 majo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message