linux-kernel - Re: [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board

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