From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guo Ren Subject: Re: [PATCH V4 00/27] C-SKY(csky) Linux Kernel Port Date: Sat, 22 Sep 2018 07:48:14 +0800 Message-ID: <20180921234813.GA5469@guoren-Inspiron-7460> References: <20180914143719.GA27689@guoren-Inspiron-7460> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann Cc: Palmer Dabbelt , linux-arch , Linux Kernel Mailing List , Thomas Gleixner , Daniel Lezcano , Jason Cooper , DTML , andrea.parri@amarulasolutions.com, Peter Zijlstra , c-sky_gcc_upstream@c-sky.com, gnu-csky@mentor.com, Thomas Petazzoni , wbx@uclibc-ng.org, Greentime Hu , Stephen Rothwell List-Id: linux-arch.vger.kernel.org On Thu, Sep 20, 2018 at 10:18:51PM -0700, Arnd Bergmann wrote: > On Thu, Sep 20, 2018 at 10:52 AM Palmer Dabbelt wrote: > > > > On Fri, 14 Sep 2018 07:37:20 PDT (-0700), ren_guo@c-sky.com 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2200-217.mail.aliyun.com ([121.197.200.217]:45365 "EHLO smtp2200-217.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725748AbeIVFkC (ORCPT ); Sat, 22 Sep 2018 01:40:02 -0400 Date: Sat, 22 Sep 2018 07:48:14 +0800 From: Guo Ren Subject: Re: [PATCH V4 00/27] C-SKY(csky) Linux Kernel Port Message-ID: <20180921234813.GA5469@guoren-Inspiron-7460> References: <20180914143719.GA27689@guoren-Inspiron-7460> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Arnd Bergmann Cc: Palmer Dabbelt , linux-arch , Linux Kernel Mailing List , Thomas Gleixner , Daniel Lezcano , Jason Cooper , DTML , andrea.parri@amarulasolutions.com, Peter Zijlstra , c-sky_gcc_upstream@c-sky.com, gnu-csky@mentor.com, Thomas Petazzoni , wbx@uclibc-ng.org, Greentime Hu , Stephen Rothwell Message-ID: <20180921234814.irZaM1mgwCMyaUCt1aJOxiK_somLj36PNFX_BYd6Hck@z> On Thu, Sep 20, 2018 at 10:18:51PM -0700, Arnd Bergmann wrote: > On Thu, Sep 20, 2018 at 10:52 AM Palmer Dabbelt wrote: > > > > On Fri, 14 Sep 2018 07:37:20 PDT (-0700), ren_guo@c-sky.com 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 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