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


On Tue, Sep 25, 2018 at 10:31 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Tue, 25 Sep 2018, Arnd Bergmann wrote:
>
> > riscv32 falls into this category: there is preliminary kernel support
> > for it, but no upstream glibc. The riscv maintainers have indicated a
> > preference that they would actually want to drop the 32-bit time_t
> > syscalls from the kernel as well, since nobody is relying on them
> > today. I don't think it makes a difference to glibc, so we'll discuss this
> > among the kernel folks.
> >
> > In general, we don't break established user ABIs as a rule, but we
> > also have lots of precedent for changing interfaces when we are
> > sure that there are no users that would complain about the change.
>
> Depending on how long the glibc ports take to be ready (previously
> submitted, but without all the other upstream toolchain components being
> ready at the time), it could also apply to ARC and NDS32.  In the ARC
> case, the kernel port has been there for years, so unlike riscv32 I
> presume you couldn't remove the old syscalls from the kernel.

For ARC that is clearly the case, yes. For nds32, we have an
existing uclibc-ng mainline port that uses the current syscall
ABI, which I see as enough precedent that I would not consider
doing an incompatible change any more, but glibc can simply
pretend that the time32 interfaces never existed on this.

       Arnd


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