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:   Wed, 20 Dec 2017 14:14:07 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Alexander Sverdlin <alexander.sverdlin@...il.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Lukasz Majewski <lukma@...x.de>,
        Hartley Sweeten <hsweeten@...ionengravers.com>,
        Russell King <linux@...linux.org.uk>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Olof Johansson <olof@...om.net>
Subject: Re: [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board

On Wed, Dec 20, 2017 at 2:00 PM, Alexander Sverdlin
<alexander.sverdlin@...il.com> wrote:
> Hi!
>
> On Wed Dec 20 13:50:28 2017 Arnd Bergmann <arnd@...db.de> wrote:
>> I'm generally more interested in the multiplatform conversion than
>> the DT conversion, and I think converting this one to multiplatform
>> isn't actually that hard, and doesn't have a significant risk for
>> regressions, the main work is to convert the clock handling.
>
> If it will be still possible to build the binary kernel of the same size after the
> conversion, I'm in for testing, otherwise it will not fit into Flash any more...

I think there is an increase in code size that comes mainly from the
common clock layer itself, plus a few bytes here and there. Obviously
the increase is much bigger if you actually enable multiple platforms.

Here is the size of the uncompressed vmlinux file with the current
clk implementation, compared to a build with a build containing the
common clk code but no clock driver, and the separate clock
implementation we have today:

   text    data     bss     dec     hex filename
4752655 1036028 128260 5916943 5a490f build/tmp/vmlinux-old-clk
4780174 1040524 128284 5948982 5ac636 build/tmp/vmlinux-common-clk
   2491    1700       0    4191    105f build/tmp/arch/arm/mach-ep93xx/clock.o

The difference would come to about 0.7% of the current image size,
I guess around 1% when the other changes are included. Is that within
the margins you have, or is this already critical?

       Arnd

Powered by blists - more mailing lists