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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180921234813.GA5469@guoren-Inspiron-7460>
Date:   Sat, 22 Sep 2018 07:48:14 +0800
From:   Guo Ren <ren_guo@...ky.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Palmer Dabbelt <palmer@...ive.com>,
        linux-arch <linux-arch@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Jason Cooper <jason@...edaemon.net>,
        DTML <devicetree@...r.kernel.org>,
        andrea.parri@...rulasolutions.com,
        Peter Zijlstra <peterz@...radead.org>,
        c-sky_gcc_upstream@...ky.com, gnu-csky@...tor.com,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        wbx@...ibc-ng.org, Greentime Hu <green.hu@...il.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [PATCH V4 00/27] C-SKY(csky) Linux Kernel Port

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@...ive.com> wrote:
> >
> > On Fri, 14 Sep 2018 07:37:20 PDT (-0700), ren_guo@...ky.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 <ren_guo@...ky.com> 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