Re: [PATCH] Y2038: provide kernel support indication

[Albert ARIBAUD <albert dot aribaud at 3adev dot fr>]

Hi Paul,

On Mon, 24 Sep 2018 23:19:56 -0700, Paul Eggert <eggert@cs.ucla.edu>
wrote :

> Albert ARIBAUD wrote:
> > 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?  
> 
> The former sounds better, at least for now. It can evolve to the latter if and 
> when the syscall set mutates. I see little advantage to starting with the latter 
> now.
> 
> 
> > 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]".  
> 
> Yes, that's the sort of thing that I expect too. But unless I'm missing 
> something, we don't have a strong need for a central repository that catalogs 
> these quirks, as they're likely to be local to single modules[

Ok, so:

- one new boolean for every new feature, which libc can read/write.
  Reading happens every time the feature is used.
  Writing happens very rarely, once when first first using / testing for
  the feature (e.g. at application start), once if using the feature
  fails (e.g. a syscall returns ENOSYS).

- two accessors (getter/setter) for every new feature if it must be
  read/set from another glibc library than libc (e.g. librt).

Cordialement,
Albert ARIBAUD
3ADEV