Skip site navigation (1)Skip section navigation (2)
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-current" 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>