Re: [PATCH] ppc64 changes common powerpc/bits headers

["Steve Munroe" <sjmunroe at us dot ibm dot com>]

> > diff -rupPN
libc23-cvstip-20020923/sysdeps/unix/sysv/linux/powerpc/bits/msq.h
> ...
> > @@ -38,11 +38,17 @@ typedef unsigned long int msglen_t;
> >  struct msqid_ds
> >  {
> >    struct ipc_perm msg_perm;    /* structure describing operation
permission */
> > +#if __WORDSIZE == 32
> >    unsigned int __unused1;
> > +#endif
> >    __time_t msg_stime;          /* time of last msgsnd command */
> > +#if __WORDSIZE == 32
> >    unsigned int __unused2;
> > +#endif
> >    __time_t msg_rtime;          /* time of last msgrcv command */
> > +#if __WORDSIZE == 32
> >    unsigned int __unused3;
> > +#endif
>
> That's stupid.  The unused field is meant to be used for sub-second
> information.  There is (fortunately) again discussion about adding
> support to the kernel.  You'd shut out ppc64 of this, doomed to live
> with full second numbers.

I am not sure how to resolve this. Your suggestion does not seem to be
correct either.

1) I have discussed this with the PowerPC32 and PowerPC64 Kernel
maintainers and they are not aware of any pending design changes related to
sub-second timing on these APIs.

2) What discussion that does exist on the topic of "high-resolution timers"
does not seem to apply to these APIs.

3) Our current implementation (both kernel and glibc) follow the other
64-bit architectures. In the absence of a specific design proposal I am
reluctant deviate from the norm.

4) The current 32-bit provisions for future expansion seem to be
inconsistent. msq.h, sem.h, and shm.h place the unused words ahead of the
time_t fields while stat.h place them after the time_t fields.  It is not
obvious what the final result should look like. It seems like timeval would
be the natural model but then msq.h, sem.h, and shm.h are in the wrong
order.

5) A single 64-bit (unsigned long int) value can support microsecond
resolution for 264144 year. With nanosecond resolution for 548 years.  This
change could be grandfathered in with a simple epoch range check.  So it is
not clear that additional space is required (beyond the existing 64-bit
time_t fields) for existing 64-bit platforms.