> > I can do this, although it will mean renaming all the uses of the semid_ds
> > and shmid_ds structures to something like kernel_semid_ds,
> > kernel_shmid_ds, etc. (my proposed change would make semid_ds and shmid_ds
> > private to the kernel, as msg_queue and shmid_kernel are now)
>
> Call them semid64_ds etc - thats not bad is it
I think I'll go with new_semid_ds, new_shmid_ds, new_msqid_ds, and
new_ipc_perm as suggested by Manfred. The kernel private structures will
be shmid_kernel, msg_queue, sem_array, and kern_ipc_perm.
I was just a little concerned about a patch that would rename a bunch of
kernel structures :)
>
> > #else
> > /* Make libc5 happy for compiles */
> > #define semid_ds old_user_semid_ds
> >
> > #endif /* __KERNEL__ */
>
> Thats a posix namespace violation. You can try and go this way but it just
> gets uglier and uglier. I made the mistake myself before now 8)
I should have made it more clear that that was really a halfhearted
suggestion... my real question was whether or not we had to support libc5
compiles at all. If we do, then we can't rename any structures in the
kernel include files. If we don't, then whatever is in the kernel source
code shouldn't matter, because it won't ever be seen when compiling any
portable software. (glibc should wrap everything specified by POSIX,
right?)
I'll re-do the patch taking this and Manfred's suggestions into account.
(the kernel private structures will be in ipc/{msg,sem,shm}.c, and the
user visible structures will be in include/linux/{msg,sem,shm}.h)
Thanks for the input,
Chris Wing
wingc@engin.umich.edu
-
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/