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.
Danny
[EMAIL PROTECTED]
On Monday 14 October 2002 15:18, Maxim Sobolev wrote:
> Linux solved the problem by introducing a new flag for {msg,shm,sem}ctl(3)
> interfaces (IPC_64), which if set tells the kernel that user supplies
> new version of the structure. The kernel itself internally keeps all
> relevant information already in IPC_64 format, doing conversion before
> returning it to user if IPC_64 isn't set. I think that for portability
> reasons we should at least consider the same or similar route.
>
> -Maxim
>
> On Mon, Oct 14, 2002 at 01:27:57PM -0400, Robert Watson wrote:
> > Yeah, this is a Known Problem, and it's quite unfortunate, actually. I
> > looked at trying to solve it -- changing the types respectively to uid_t,
> > gid_t, and mode_t, but it involved a lot of ABI munging because the
> > structures are shared between the userland interface and the kernel
> > implementation. The result is that any change in the kernel structure
> > really requires you to break out the user structures from the kernel
> > structure, which requires a lot of work. Also, ipc_perm is shared
> > between all three SysVIPC services, and to compound things, there are
> > already ofoo() interfaces for older versions of the structures. My
> > belief is that seperating the user and kernel structures is really
> > necessary -- making a kipc_perm, etc, so we can better support
> > fine-grained locking and extensible security. However, someone has to do
> > the grunt work, and last time I tried, I spent several days and only made
> > a bit of progress. If you want to give a first pass at breaking out the
> > user and kernel structures and send a patch, I'll be happy to work with
> > you to get it integrated. I think the steps are:
> >
> > (1) Divorce user and kernel structures for all of the SysVIPC interfaces,
> > and provide functions to map between them as necessary.
> >
> > (2) Remove the original compatibility interfaces left over from eons ago
> > (and figure out how many eons ago so we know what ABIs we're finally
> > removing).
> >
> > (3) Define new userland versions of necessary structures and create a new
> > set of ofoo() and foo() interfaces based on the change.
> >
> > (4) Go back through and dribble the kernel structures with new toys, such
> > as 'struct label', etc.
> >
> > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> > [EMAIL PROTECTED] Network Associates Laboratories
> >
> > On Mon, 14 Oct 2002, Vladimir B.
Grebenschikov,Moscow,408-7227,123-4567,Some-info wrote:
> > > Hi
> > >
> > > I have found that SysVIPC functions uses structure with short uid/gid
> > > types.
> > >
> > > What is valid solution ?
> > >
> > > Change types to uid_t/gid_t (but this will broke binary compatibility)
> > > Change syscalls to old_* and add new with "right" structures,
> > > or something else ?
> > >
> > > struct ipc_perm {
> > > ushort cuid; /* creator user id */
> > > ushort cgid; /* creator group id */
> > > ushort uid; /* user id */
> > > ushort gid; /* group id */
> > > ushort mode; /* r/w permission */
> > > ushort seq; /* sequence # (to generate unique msg/sem/shm id) */
> > > key_t key; /* user specified msg/sem/shm key */
> > > };
> > >
> > > --
> > > Vladimir B. Grebenschikov
> > > [EMAIL PROTECTED], SWsoft, Inc.
> > >
> > > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > > with "unsubscribe freebsd-arch" in the body of the message
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
