I don't think it is really a problem if support for the new msqid_ds
doesn't go into the older libc versions. One can still locally
redefine msgctl if needed, but the typical application of msgctl is just
a IPC_RMID call and msqid_ds is irrelavent there -- large messages and
queues can still be used, they just aren't accurately reported.
What were you thinking of doing to clean up the two header file #ifdefs? To
maintain (wrt 64 bit) the size of msqid_ds in the kernel code I used the
following:
union { void * __wwait ; unsigned int msg_cbytes; } c;
union { void * __rwait ; unsigned int msg_qbytes; } q;
and then refer to c.msg_cbytes or q.msg_qbytes. It didn't require ifdefs
but also isn't particularily nice looking. My rational for using the ifdefs
in the user space code was because the structure names had to be msg_cbytes and
msg_qbytes.
> But one thing seems to be wrong. The changes to the kernel which your
> patch imply (I haven't seen the actual kernel changes) you use an very
> ugly trick to detect whether an old library is running on top of a
> large kernel (setting the value to zero).
>
> Why not only define a new opcode for msgctl which requires the new
> value in the new position. Speaking in glibc terms with your changes:
>
> if (__kernel_large_msqqueue_support == 0)
> return __ipc (IPCOP_msgctl, msqid, cmd, 0, buf);
> else
> return __ipc (IPCOP_msgctl32, msqid, cmd, 0, buf);
>
> This is a much cleaner way and nothing (e.g., segvs) can happen.
This would be better. I have to admit that doing it the other way bothered
me -- I am somewhat suprised that nobody else commented on it.
The only bad thing about doing this (besides it being more work:) is that
it won't work on alpha and a new msgctl syscall will be needed there (the
ipc multiplexer is used on all platforms except alpha).
Peeter
-- Peeter Joot peeterj@ca.ibm.com IBM DB2 Operating System Services 416-448-3359 (tie line 778)- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/