Re: glibc 2.29: Reminder, only ~3 weeks to freeze!

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 17 Dec 2018, Siddhesh Poyarekar wrote:

> On 16/12/18 11:52 PM, Albert ARIBAUD wrote:
> > Last cycle, inclusion the Y2038 patches was postponed. I would like to
> > get them in for this release. A first few of them have landed in
> > already, I can repost the remainder of the series.
> 
> Please add it to the wiki when you re-post.

I think it's premature to repost anything involving use of new kernel 
interfaces.  Have the questions of what the kernel will provide for 64-bit 
architectures (regarding new names for old syscall numbers, or new names 
and numbers that are equivalent to old syscalls - and regarding new 
syscalls for the itimerval / rusage cases) been resolved yet?  Once those 
questions have been resolved, I expect we'll need to go through several 
iterations on patches that do no more than define __ASSUME_* macros (with 
very carefully written and reviewed multi-paragraph comments that make 
absolutely clear and unambiguous to readers, who haven't read any of the 
previous discussions, exactly what those macros being defined or undefined 
mean for the different kinds of configurations I list at 
<https://sourceware.org/ml/libc-alpha/2018-09/msg00448.html>), plus a few 
example uses of those macros to help in the review - the review being more 
for getting the right definition of the internal interfaces such as 
__ASSUME_* macros, than for the substance of patches using those 
interfaces.  But those would best be posted when more people are going to 
be around to review them.

If the kernel gets new timespec-based rusage etc. syscalls 
unconditionally, there will also be the question of what glibc bindings 
there should be to such syscalls.  Should such bindings use struct 
timespec as the type in the interface, and so have two versions on systems 
where time_t is currently 32-bit?  Or should they use some timespec-like 
type where the time is always 64-bit, but which is not compatible (in the 
C sense) with struct timespec, so as to have only one version everywhere?  
(And should those bindings have fallback implementations that use the 
existing timeval-based syscalls and convert the data, to work on existing 
kernels.)

-- 
Joseph S. Myers
joseph@codesourcery.com