Date: Wed, 16 Oct 2002 19:50:45 -0400 From: "Danny J. Zerkel" <dzerkel@columbus.rr.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Maxim Sobolev <sobomax@FreeBSD.ORG>, "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: <200210161950.45338.dzerkel@columbus.rr.com> In-Reply-To: <Pine.NEB.3.96L.1021016004135.36711H-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1021016004135.36711H-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210161950.45338.dzerkel>