linux-kernel - Re: [GIT PULL] C-SKY(csky) Port for Linux 4.20

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 30 Oct 2018 20:50:48 +0900
From:   Yoshinori Sato <ysato@...rs.sourceforge.jp>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Guo Ren <ren_guo@...ky.com>,
        Marc Zyngier <marc.zyngier@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Rob Herring <robh@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        c-sky_gcc_upstream@...ky.com, guoren1983@...il.com
Subject: Re: [GIT PULL] C-SKY(csky) Port for Linux 4.20

On Mon, 29 Oct 2018 18:44:59 +0900,
Arnd Bergmann wrote:
> 
> On Sun, Oct 28, 2018 at 10:11 PM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > Arnd,
> >  I was kind of hoping/expecting to get an explicit ack for this from
> > you, since it's a new architecture.
> >
> > Good to merge?
> 
> Yes.
> 
> For the pull request (in case you want to add it to the merge changelog):
> 
> I did a thorough review of the ABI, which as usual mainly consists of spotting
> any files that don't use the asm-generic ABI itself, and having it changed to
> it matches exactly what we do on other new architectures.
> 
> I also looked at every other patch and commented on maybe half of them
> where I saw something that did not quite seem right. Others have reviewed
> specific patches in greater depth. I'm sure that one could fine more of the
> minor details, but as long as they are not ABI relevant, they can be fixed
> later.
> 
> The only patch that is part of the ABI and that nobody reviewed is the
> signal handling. This is one of the areas I never worked on in much detail.
> I did not see anything wrong with it, but I also don't know what the problems
> with the other architectures are here, and we seem to be hitting issues
> occasionally, and we never managed to generalize this enough for new
> architectures to have a trivial implementation.
> 
> I was originally hoping that we could have the 64-bit time_t interfaces
> ready in time to completely drop the 32-bit ones, but that did not
> happen. We might still remove them in the next merge window
> depending on whether the libc upstream people prefer to keep them
> or not.
> 
> Acked-by: Arnd Bergmann <arnd@...db.de>
> ---
> You may note that Guo rebased the series on top of v4.19. I tried
> to explain a while ago that it's better not to do that, but I suppose he
> was trying to add the last-minute Acks and it seemed like a good idea.
> 
> Guo, in the future I recommend to add all patches on top of the latest
> -rc1 (or maybe a later -rc) but not rebase them or pull in the mainline
> kernel into your own tree.
> 
> One more general comment: I think this may well be the last new CPU
> architecture we ever add to the kernel. Both nds32 and c-sky are made
> by companies that also work on risc-v, and generally speaking risc-v
> seems to be killing off any of the minor licensable instruction set projects,
> just like ARM has mostly killed off the custom vendor-specific instruction
> sets already. If we add another architecture in the future, it may instead
> be something like the LLVM bitcode or WebAssembly, who knows?
> 

I have one another port.
Now we have a build environment so we can not merge right away,
but I'd like to update it to the latest within a few months.

>        Arnd

-- 
Yosinori Sato