On Fri, Sep 14, 2018 at 4:37 PM Guo Ren <ren_guo@xxxxxxxxx> wrote:
> On Wed, Sep 12, 2018 at 04:30:36PM +0200, Arnd Bergmann wrote:
> > On Wed, Sep 12, 2018 at 3:25 PM Guo Ren <ren_guo@xxxxxxxxx> wrote:
> >
> > One big question for me is what to do about time_t. Deepa and I are
> > in the process of finalizing the system call ABI for 32-bit architectures
> > with 64-bit time_t, but we are not done yet and it won't be complete
> > for 4.20. If you target 4.21, that could be a chance to make csky the
> > first architecture to only need the 64-bit time_t interface, with the
> > corresponding user space changes.
> y2038 is very important and csky32 has the issue. But 4.21 is too late for
> us, we really want to get into kernel.org as soon as possible.
> We could remove 32-bit time_t in future.
Not really: the way we deal with user-visible APIs in the kernel, it's
practically impossible to remove something that was working before,
since there may always be users relying on it. This is why it is so
important that we get the ABI right at the first try.
We can always add new ABIs later, and that's what we're doing with
all the other 32-bit architectures as well: each system call that takes a
32-bit time_t argument also needs to get the corresponding 64-bit
replacement, and then we have to keep them both around.
However, once the 64-bit syscalls are there, you don't need to
use them, so if you merge the glibc port after both csky and
the time64 syscalls are merged upstream, you can choose
to only support the time64 syscalls rather than making it a compile
time decision in each application. If you merge the glibc port
before migrating to 64-bit syscalls, glibc will also have to support
both indefinitely for compatibility with existing binaries.
One level below that, you can of course choose to build
a distro with only 64-bit time_t regardless of whether there
is still support for 32-bit time_t in kernel and glibc or not.
Arnd
