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

[Guo Ren]

On Thu, Sep 20, 2018 at 10:18:51PM -0700, Arnd Bergmann wrote:
> 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
Thx for the schedule info.

> >
> > 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).
Seems time schedule is OK. If we make csky get into linux-4.20, then csky glibc
port could remove 32-bit time_t in patchset before glibc 2.29 release.

> 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.
Seems that's no problem.

Best Regards
 Guo Ren