Re: [PATCH 0/7] Implement proposed POSIX _clockwait variants of existing _timedwait functions

[Mike Crowe <mac at mcrowe dot com>]

On Wednesday 06 March 2019 at 21:15:18 +0000, Joseph Myers wrote:
> On Tue, 5 Mar 2019, Adhemerval Zanella wrote:
> 
> > > The mq_clockreceive and mq_clocksend functions corresponding to
> > > mq_timedreceive and mq_timedsend require kernel changes before they can be
> > > implemented in glibc.
> > 
> > Should we add them as ENOSYS as generic stubs in this version?
> 
> I'd expect any generic stubs to work with CLOCK_REALTIME without returning 
> ENOSYS errors in that case.

Yes. However, I wasn't planning to implement mq_clockreceive and
mq_clocksend or propose them for POSIX now. Apparently they can be
described as being "future direction". I'd rather get the other functions
completed first.

It would be straightforward to add them with support for CLOCK_REALTIME
only, but I'm not sure that it really brings much value. Adding
CLOCK_MONOTONIC support at the same time as the new functions would mean
that autoconf scripts would know that CLOCK_MONOTONIC was supported if the
functions were found, rather than having to fall back at runtime.

> > > The changes have been tested with "make check" on x86_64 and arm64. Earlier
> > > versions were tested on arm. I haven't updated the ChangeLog, NEWS or
> > > architecture abilists yet (so some tests fail on arm64), but will do so if
> > > the rest of the changes are acceptable.
> > 
> > Are arm64 failures related to the patchset itself?
> 
> My reading is that they result from missing ABI updates.  (Each patch 
> ought to update all relevant ABI lists to avoid introducing failures.)

Yes. I did spend a while updating various ABI lists, but I kept having to
change them each time there was a glibc release, so I decided that I'd wait
until the rest of the changes were acceptable. Similarly for NEWS and
ChangeLog.

Thanks, and thanks for all the other comments. I'll update the patches
accordingly.

Mike.