[parisc-linux] what's up with the ipc syscalls?

[Thomas Bogendoerfer]

On Sun, Nov 02, 2003 at 05:56:27PM -0500, Carlos O'Donell wrote:
> On Sun, Nov 02, 2003 at 10:42:00PM +0100, Thomas Bogendoerfer wrote:
> > On Sun, Nov 02, 2003 at 10:12:52AM -0800, Randolph Chung wrote:
> > > anyway, if we are only supporting IPC_64, then why mask off the IPC64
> > > bit in the wrapper? if the ipc/utils.c stuff isn't there, wouldn't it
> > > default to doing the right thing when IPC_64 is set?
> > 
> > look at the switch statements in msg.c/sem.c/shm.c. If you don't mask
> > off IPC_64, the cases don't match.
> > 
> > > right now glibc *doesn't* call the syscall with IPC_64, but i'm about to
> > > make it do that again.
> > 
> > I don't think this is a good idea, because by checking for IPC_64 we
> > could see, whether an old glibc is used and could convert structs
> > (see sys_parisc.c:sys_shmctl_broken()).
> 
> There is no such thing as that "old glibc" we have always had
> __ASSUME_IPC64. What support are we looking to preserve?

glibc 2.2.x, some weeks before woody went final. For a closer date
check the date of my sys_parisc.c commit.

Since there might be still binaries in woody, which are compiled
with an such an "old" glibc, we will break this binaries. The suggested
change is an change of the kernel ABI, so I would avoid it. The problem
with this "old" glibc was, that the structs for shmctl and friends
weren't properly aligned for 64bit. I've changed that and also decided
to get rid of IPC_64, because that's x86 crap.

Adding the 2.4 changes to the 2.6 kernel should fix everything.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                 [ Alexander Viro on linux-kernel ]