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

[Carlos O'Donell]

> I had some thoughts about the conversion stuff, I've added to work
> around problems introduced because of the change of some structures in
> glibc/kernel. I finally realized, that these conversion only works,
> if the "old glibc" is still installed together with the old binary.
> That's because the newer glibcs don't set the IPC_64 bit when doing 
> the syscall, but the old binary still uses the wrong structs, so the
> conversion routine never triggers. I think it's really time to remove that
> crap. Below is an compiled but not booted patch, which removes it and also
> forward ports the necessary bits in ipc/util.c from 2.4. 

The following things confuse me.

a. Our glibc never set IPC_64, we had pass-thru assembly syscall
   wrappers. Why? Because we don't have an IPC multiplexor, none of the
   generic glibc code can be used by hppa.

So I don't understand some of your comments about "old glibc setting
IPC_64."

> If someone also wants to change glibc, feel free. I still think changing
> glibc is a bad idea, because this new glibc won't work with a current 2.4
> kernel.

I believed we had the following scenario:

a. Old glibc never called with IPC_64.
b. Kernel turned IPC_64 on for us so we get the new style structs.
c. Apps get new style structs without calling IPC_64.

Now we wish to have the hack in the kernel removed, but apps exist that
expect newstyle structs without calling IPC_64. Thus glibc has to
call the syscall with IPC_64 to get the right value back to userspace.

AFAIK the following is required:

a. Remove kernel hacks (Thanks Thomas!).
b. Add glibc code to turn IPC_64 on for all the afflicted syscalls.
c. Eventually when all the apps disappear we can toss out the code from
   glibc.

Thomas, did I get this right?

Cheers,
Carlos.