Re: [PATCH V4 00/27] C-SKY(csky) Linux Kernel Port

[Arnd Bergmann]

On Thu, Sep 20, 2018 at 10:52 AM Palmer Dabbelt <palmer@xxxxxxxxxx> wrote:
>
> On Fri, 14 Sep 2018 07:37:20 PDT (-0700), 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:
> I don't want to hijack this thread, but in RISC-V land we were hoping to have a
> user ABI free of 32-bit time_t.  Our 32-bit glibc ABI hasn't been finalized
> yet, and when I talked to the glibc guys a few weeks ago they were happy to let
> us wait until 32-bit time_t can be removed before we stabilize the ABI.  We've
> been maintaining out-of-tree glibc patches for a while now, so I'd really like
> to get them into the next glibc release.
>
> Mapping out the schedule more explicitly, as I'm terrible with dates:
>
> * 4.19-rc4 was 2018-09-16
> * 4.19 should be 2018-10-21
> * 4.20 should be 2019-01-13 (skipping 2 weeks for the holidays)
> * 4.21 merge window should close 2019-01-27
> * glibc 2.29 is scheduled for 2019-02-01
>
> That's very tight, but assuming we at least have a prototype of the API so we
> can get the rv32i glibc patches in much earlier it might be OK.  There was some
> talk of being able to use some workarounds to do a 32-bit time_t user ABI
> without the cooresponding kernel ABI, so we could always go down that route to
> start and then decide to deprecate or not deprecate the 32-bit kernel ABI at
> the last minute -- not something I'm fond of doing, but an option.
>
> How close to done do you think the 32-bit time_t will be by the end of the 4.20
> merge window?  If it's close enough to start our glibc push then that might be
> OK.

It will be a bit of a stretch, but it's possible. Most syscalls are
done in linux-next,
I have a few more pending, and only clock_adjtime is really missing now (I had
some earlier patches that I could revive).

My plan was to get that all into 4.20, and then have a conversation about the
actual syscall table changes in 4.21. If we need it for both csky and rv32,
we might just change the generic syscall table that way in 4.21 without
changing all the other ones along with them. I don't want to drag things out
over too many merge windows though, and my plan was to do all architectures
together to simplify the version checks in the libc code to only have to check
for a single version.

         Arnd