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 Florian,

On Tue, 25 Sep 2018 12:58:25 +0200, Florian Weimer <fweimer@redhat.com>
wrote :

> * Albert ARIBAUD:
> 
> > - 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).  
> 
> I'm still surprised that this is needed.  Why can't applications call
> the function in question and react to a well-documented error code?

These features are for glibc rather than for applications; they are
here for glibc to remember whether a Y2038 feature is available in the
kernel over which it currently runs.

Implementations for 64-bit time interfaces which rely on syscalls need
to be able to fall back to 32-bit-time syscalls if 64-bit-time syscalls
fail. Once a 64-bit-syscall has failed, it makes little sense to try it
again later; glibc can save the effort and directly call the 32-bit
syscall.

Applications, on the other hand, would call the 64-bit-time interface
regardless of the feature state. Whether this call would translate
into 64-bit-time or 32-bit-time syscalls would be invisible to them. 

> Thanks,
> Florian

Cordialement,
Albert ARIBAUD
3ADEV


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