linux-kernel - Re: [PATCH 00/31] Andes(nds32) 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAK8P3a0tP4NrOzaHnndp2UO_a9swSrqscPM1h5N=Hit3pX_DxA@mail.gmail.com>
Date:   Wed, 8 Nov 2017 11:26:37 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Greentime Hu <green.hu@...il.com>
Cc:     Greentime <greentime@...estech.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Networking <netdev@...r.kernel.org>
Subject: Re: [PATCH 00/31] Andes(nds32) Linux Kernel Port

On Wed, Nov 8, 2017 at 6:54 AM, Greentime Hu <green.hu@...il.com> wrote:
> This patchset adds core architecture support to Linux for Andestech's
> N13, N15, D15, N10, D10 processor cores.
>
> Based on the 16/32-bit AndeStar RISC-like architecture, we designed the
> configurable AndesCore series of embedded processor families. AndesCores
> range from highly performance-efficient small-footprint cores for
> microcontrollers and deeply-embedded applications to 1GHz+ cores running
> Linux, covering general-purpose N-series cores for a wide range of computing
> need, DSP-capable D-series cores for digital signal control,
> instruction-extensible E-series cores for application-specific acceleration,
> and secure S-series cores for best protection of the most valuable.

I looked at the entire patch series now and commented on anything I noticed
that could be improved, overall this looks very nice, great work!

Most of my comments are about tiny details that are easy to address.

I see two areas that need to be looked at carefully, and that may take a
few more rounds to get right:

- In the user space ABI, you have a couple of things that differ from the
  normal asm-generic definitions, i.e. s few syscall entry points and some
  types in asm/posix-types.h. I guess you did that to remain compatible
  with an older glibc port, but IMHO this compatibility should be broken
  in favor of having the standard ABI before the port gets merged.

- For the boot interface, you need to clearly define what can be expected
  and what cannot. This involves the presence of the l2cc, the physical
  memory address, the built-in dtb, and probably a few more things I
  missed. For long-term maintainability, you probably want to ensure that
  you can build a kernel that runs on as much diverse hardware as possible.

       Arnd