From owner-freebsd-current Wed Oct 16 2:31:11 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C298F37B401; Wed, 16 Oct 2002 02:31:09 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8465F43EB3; Wed, 16 Oct 2002 02:31:05 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226]) by baraca.united.net.ua (8.11.6/8.11.6) with ESMTP id g9G9Usu39477; Wed, 16 Oct 2002 12:30:55 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.6/8.12.5) with ESMTP id g9G9Up6N011223; Wed, 16 Oct 2002 12:30:51 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.6/8.12.5/Submit) id g9G9UnZb011222; Wed, 16 Oct 2002 12:30:49 +0300 (EEST) Date: Wed, 16 Oct 2002 12:30:48 +0300 From: Maxim Sobolev To: Terry Lambert Cc: Robert Watson , "Danny J. Zerkel" , "Vladimir B. Grebenschikov,Moscow,408-7227,123-4567,Some-info" , freebsd-arch@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: short uid/gid Message-ID: <20021016093048.GB10908@vega.vega.com> References: <3DAD2B79.AD5412CA@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <3DAD2B79.AD5412CA@mindspring.com> User-Agent: Mutt/1.4i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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