This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH] RE: msgctl() on MIPS, n32 ABI.


> 2007-01-10  Atsushi Nemoto <anemo@mba.ocn.ne.jp>
> 
> 	* sysdeps/unix/sysv/linux/mips/mips64/syscalls.list: 
> Remove msgctl,
> 	shmctl, and semctl.
> 	* sysdeps/unix/sysv/linux/mips/misp64/semctl.c,
> 	sysdeps/unix/sysv/linux/mips/mips64/shmctl.c,
> 	sysdeps/unix/sysv/linux/mips/mips64/msgctl.c: New files.

You know, this IPC_64 is a gross hack (on ARM too). Why should a 64 bit
task, running on a 64 bit kernel have to pass a flag to indicate that it
wants 64 bit IPC?

Why /don't/ we need a FS_64 flag when we are calling utime(), et cetera?

Calling the kernel shouldn't be anything more than loading some
registers directly from the applications's parameters, and hitting the
software trap. Any hacky compatibility flags should be encapsulated in
the kernel.

Maybe IPC_64 should really have been an opposite flag, IPC_32, which is
positively asserted when compatibility is required.

It's not too late to do that. Add an IPC_32, use that internally in the
compatibility wrappers, and ignore any IPC_64 that is set by glibc. Then
fix glibc so that if --enable-kernel is above a certain version, it
doesn't use its wrappers any more, and consequently doesn't pass that
flag any longer.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]