> > This will only be a problem if someone wants to include the kernel headers
> > directly in his/her application (did the old libc5 do it this way,
> > though?)
>
> Yes. So you just keep the old one around and name the new ones differently.
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)
What about something like this (in include/linux/sem.h):
/* this defines user_semid_ds and old_user_semid_ds */
#include <asm/sem.h>
#ifdef __KERNEL__
struct semid_ds {
struct ipc_perm sem_perm;
time_t sem_otime;
time_t sem_ctime;
struct sem *sem_base;
struct sem_queue *sem_pending;
struct sem_queue **sem_pending_last;
struct sem_undo *undo;
unsigned long sem_nsems;
};
#else
/* Make libc5 happy for compiles */
#define semid_ds old_user_semid_ds
#endif /* __KERNEL__ */
> > I thought that it would be cleaner to just start over with new structures.
> > I haven't looked at the relevant standards committee documents (SuS), so
> > perhaps I should be leaving more space for other things...
>
> I agree. Expand the message counts/sizes to 32bit too. We dont need to use
> the top 16 yet but it will happen.
Already done.
Thanks,
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/