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: <CAEbi=3c=hTCcUOPs+Fc10srzTFsB4MnVxgcFydz12-jH0ZXjog@mail.gmail.com>
Date:   Wed, 29 Nov 2017 16:39:51 +0800
From:   Greentime Hu <green.hu@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
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>,
        Vincent Chen <deanbo422@...il.com>,
        DTML <devicetree@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        David Howells <dhowells@...hat.com>,
        Will Deacon <will.deacon@....com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        linux-serial@...r.kernel.org, Vincent Chen <vincentc@...estech.com>
Subject: Re: [PATCH v2 25/35] nds32: Build infrastructure

2017-11-27 22:21 GMT+08:00 Arnd Bergmann <arnd@...db.de>:
> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu <green.hu@...il.com> wrote:
>
>> diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu
>> new file mode 100644
>> index 0000000..6b4013f
>> --- /dev/null
>> +++ b/arch/nds32/Kconfig.cpu
>> @@ -0,0 +1,131 @@
>> +comment "Processor Features"
>> +
>> +config CPU_BIG_ENDIAN
>> +       bool "Big endian"
>> +       def_bool n
>> +
>> +config CPU_LITTLE_ENDIAN
>> +       bool "Little endian"
>> +       def_bool y
>
> These must be mutually exclusive, you surely get some build error if you try to
> set both here.
>
> You can either make it a 'choice' statement to pick between the two, or you
> can make CPU_LITTLE_ENDIAN a silent option like
>
> config CPU_BIG_ENDIAN
>        bool "Big endian"
>
> config CPU_LITTLE_ENDIAN
>        def_bool !CPU_BIG_ENDIAN
>

Thanks. I will fix it in the next version patch.

>> +config CPU_CACHE_NONALIASING
>> +       bool "Non-aliasing cache"
>> +       help
>> +         If this CPU is using VIPT data cache and its cache way size is larger
>> +         than page size, say N. If it is using PIPT data cache, say Y.
>> +
>> +         If unsure, say Y.
>
> Can you determine this from the CPU type?

There is no cpu register to determine it. It also depeneds on page
size and way size however page size is configurable by software.
These codes are determined at compile time will be benefit to code
size and performance.
IMHO, I think it would be better to be determined here.

>> +choice
>> +       prompt "Memory split"
>> +       depends on MMU
>> +       default VMSPLIT_3G
>> +       help
>> +         Select the desired split between kernel and user memory.
>> +
>> +         If you are not absolutely sure what you are doing, leave this
>> +         option alone!
>> +
>> +       config VMSPLIT_3G
>> +               bool "3G/1G user/kernel split"
>> +       config VMSPLIT_3G_OPT
>> +               bool "3G/1G user/kernel split (for full 1G low memory)"
>> +       config VMSPLIT_2G
>> +               bool "2G/2G user/kernel split"
>> +       config VMSPLIT_1G
>> +               bool "1G/3G user/kernel split"
>> +endchoice
>
> I think you mentioned that the 1GB configuration is quite common, how
> about making VMSPLIT_3G_OPT the default here?

We use 1GB in our fpga platform, but I am not sure our customer's
config and their user space program may use bigger memory space.
Anyway, we will discuss it to decide the default value.
Thanks for your suggestion.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ