This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Y2038: provide kernel support indication


Hi Paul,

Le Mon, 24 Sep 2018 14:50:34 -0700, Paul Eggert <eggert@cs.ucla.edu> a
écrit :

> On 9/24/18 2:34 PM, Albert ARIBAUD wrote:
> > Right now we can use the bits in __y2038_linux_support to indicate
> > level of support (when positive) or reasons for not supporting (when
> > negative). That's 31 distinct flags.  
> 
> Rather than trying to shoehorn this into a single central integer or 
> bitset that governs everything that could go wrong or right with Y2038, 
> how about having a separate boolean (or whatever) variable for each 
> feature? That way, only code that is worried about that feature needs to 
> know about the variable, and it's easier to add or remove variables as 
> the need for them is discovered or abandoned.

How would each 'feature' be defined? For instance, right now, either
the Linux kernel has no Y2038-proof syscalls at all, or it has a known
list of them (added in the kernel Y2038 syscall branch). Would that be
one 'feature', on the grounds that later kernels will provide at least
the same set, and possible a larget set, of Y2038 syscalls? Or as many
features as there are syscalls, on the grounds that some of these
syscalls may one day disappear?

> >    /* Linux kernel does or does not provide clock_gettime64 syscall.  */
> >    #define Y2038_FEATURE_LINUX_CLOCK_GETTIME64 1
> >
> >    /* Linux kernel does or does not provide clock_settime64 syscall.  */
> >    #define Y2038_FEATURE_LINUX_CLOCK_SETTIME64 2  
> 
> Will there ever be a kernel that provides one syscall but not the other? 
> We shouldn't need variables for each theoretically-possible platform, 
> only for the platforms that exist, or are likely to.

Those were examples only. Right now, apart from a general "architecture
now has support for Y2038 syscalls" feature, the only feature I can see
will happen is "syscall X has quirk Y  [for architecture Z]". What
other sort of feature should we expect?

Cordialement,
Albert ARIBAUD
3ADEV


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]