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: <9ca5caed-a68f-f131-dfb6-d187614ff9ee@gmail.com>
Date:   Mon, 17 Jan 2022 18:37:12 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Michał Mirosław <mirq-linux@...e.qmqm.pl>
Cc:     Jonathan Hunter <jonathanh@...dia.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        Thierry Reding <thierry.reding@...il.com>,
        linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-tegra@...r.kernel.org
Subject: Re: [PATCH 0/2] i2c: tegra: allow compiling out support for Tegra's
 special constrollers

17.01.2022 00:39, Michał Mirosław пишет:
> On Sun, Jan 16, 2022 at 09:34:42PM +0300, Dmitry Osipenko wrote:
>> 16.01.2022 21:03, Michał Mirosław пишет:
>>> On Sun, Jan 16, 2022 at 08:54:08PM +0300, Dmitry Osipenko wrote:
>>>> 16.01.2022 19:02, Michał Mirosław пишет:
>>>>> To patches that, combined, reduce I2C driver's code by ~2kB and a bit
>>>>> from runtime overhead for non-Tegra20 or non-Tegra210 builds.
>>>>>
>>>>> Michał Mirosław (2):
>>>>>   i2c: tegra: allow DVC support to be compiled out
>>>>>   i2c: tegra: allow VI support to be compiled out
>>>>>
>>>>>  drivers/i2c/busses/Kconfig     | 16 ++++++++++++++++
>>>>>  drivers/i2c/busses/i2c-tegra.c | 35 +++++++++++++++++++++-------------
>>>>>  2 files changed, 38 insertions(+), 13 deletions(-)
>>>>>
>>>>
>>>> 2KB is a too small difference to justify the ifdefs and Kconfig entries,
>>>> IMO.
>>>
>>> Maybe I should have mentioned that it's ~20%? With my "embedded" hat on:
>>> I think it might be small, but sometimes it is the difference between
>>> bootable kernel or one too big.
>>
>> 10KB is a small size too. I'm very doubtful that such changes make any
>> real difference in practice.
>>
>> Much more practical should be to modularize more kernel code. You should
>> be able to squeeze zImage down to 3MB without any code changes by
>> toggling more kernel config options to =m. Try to use grate_defconfig
>> [1] for the base, that is what postmarketOS kernel build uses.
> 
> For normal system this solution is workable. But for recovery, where you
> have to fit kernel+initrd in whatever small partition is provided (like
> eg. in Transformers 8MiB), it becomes a problem from time to time.
> (In this case, modules make it worse due to additional overhead in
> kernel and userspace).

My point is that 2KB very likely won't change anything for you. I'd
suggest to take a look at a more "fat" drivers, like DRM/host1x for
example. I suppose it should be possible to save at least couple
hundreds KB by trimming those fat drivers.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ