From owner-freebsd-current Wed Oct 16 16:48:42 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 5D98537B401; Wed, 16 Oct 2002 16:48:41 -0700 (PDT) Received: from clmboh1-smtp5.columbus.rr.com (clmboh1-smtp5.columbus.rr.com [65.24.0.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id E72A143E8A; Wed, 16 Oct 2002 16:48:39 -0700 (PDT) (envelope-from dzerkel@columbus.rr.com) Received: from zoomer (dhcp065-024-067-163.columbus.rr.com [65.24.67.163]) by clmboh1-smtp5.columbus.rr.com (8.11.2/8.11.2) with ESMTP id g9GNm8004213; Wed, 16 Oct 2002 19:48:08 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: "Danny J. Zerkel" Organization: Zerkular Systems To: Robert Watson Subject: Re: short uid/gid Date: Wed, 16 Oct 2002 19:50:45 -0400 User-Agent: KMail/1.4.3 Cc: Maxim Sobolev , "Vladimir B. Grebenschikov,Moscow,408-7227,123-4567,Some-info" , freebsd-arch@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200210161950.45338.dzerkel@columbus.rr.com> 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 Wednesday 16 October 2002 00:43, Robert Watson wrote: > On Tue, 15 Oct 2002, Danny J. Zerkel wrote: > > At least for our Linux emulation layer, supporting IPC_64 would be one > > of the pieces (probably the main one) keeping The Sims from running. > > The other thing we are missing is the Linux ioctl() interface for > > reading MSDOSFS directories, but that may be optional. > > > > I will eventually take a look at this (IPC_64) if the scheduling fairy > > brings me the time. > > 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. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Network Associates Laboratories Well, the scheduling fairy is very stingy. I haven't looked at what Solaris does for this. I have used there large file support mechanism in libraries, and something similar may be appropriate, to maintain binary compatibility. It could even be temporary until the 5.0-release, if it were done quickly. I guess that counts me out. After 5.0 it would probably be necessary to keep the compatibility stuff around until 6.0. Danny J. Zerkel dzerkel@columbus.rr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message