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,

On Wed, 19 Sep 2018 09:11:18 -0700, Paul Eggert <eggert@cs.ucla.edu>
wrote :

> Albert ARIBAUD (3ADEV) wrote:
> > +/* Indicates Y2038 support.
> > + * 0 means no suppport
> > + * > 0 means (some) support
> > + * < 0 means support is broken
> > + * Can be read directly from within libc linux-related files.
> > + * Can be written non-zero to indicate support or lack thereof.
> > + */
> > +extern int __y2038_linux_support;  
> 
> This variable needs a better comment, since it's not clear from that comment 
> what it's for. In the current branch, I don't see any code setting the variable 
> to a positive value; it defaults to 0 and if any glibc code discovers anything 
> that looks like a y2038 bug, the variable is set to -1.
> 
> So it looks like a cache: as glibc discovers y2038 bugs, it uses the cache to 
> avoid trying to invoke system calls that it knows will fail anyway with ENOSYS, 
> or something like that. If that's the intent, it needs to be documented in the 
> variable.
>
> However, I imagine that some kernels will have some y2038 bugs but not others. 
> For example, clock_gettime and related functions might work fine on a particular 
> kernel, but some ioctls might not work (or might work for some devices but not 
> others) due to device-drivers not being y2038-safe. How is __y2038_linux_support 
> supposed to reflect this more-complicated situation?

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.

If we want to be able to use more than 31 bits, we could reuse the
bitset_t type of the posix/regex_internal.h file and make the variable
a bitset_t. Then we could define an arbitrary number of Y2038 features /
quirks / bugs as bit indices:

  /* Y2038 unique feature/quirk/bug identifiers.  */

  /* Kernel does or does not support Y2038 globally.  */
  #define Y2038_FEATURE 0

  /* 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
  /* etc.  *.

  [...]

  /* Linux kernel clock_gettime64 implementation has quirk 'XYZ'
  #define Y2038_FEATURE_LINUX_CLOCK_GETTIME64_XYZ 42
  /* etc.  */

(there could be a set of indices for Linux, another for BSD, etc.)

For glibc modules which could not directly access the variable (and
thus could not use the inline bitset_t functions, we would provide
getters and setters named after their bitset_t equivalents:

  bool __y2038_kernel_feature_contain(int feature);
  bool __y2038_kernel_feature_set(int feature);
  bool __y2038_kernel_feature_clear(int feature);

Comments?

Cordialement,
Albert ARIBAUD
3ADEV


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