linux-kernel - Re: [PATCH] console - Add configurable support for console charset translation

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20080604103353.GC27335@cs181133002.pp.htv.fi>
Date:	Wed, 4 Jun 2008 13:33:53 +0300
From:	Adrian Bunk <adrian.bunk@...ial.fi>
To:	Tim Bird <tim.bird@...sony.com>
Cc:	linux-tiny <Linux-tiny@...enic.com>,
	linux-embedded <linux-embedded@...r.kernel.org>,
	linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] console - Add configurable support for console charset
	translation

On Mon, Jun 02, 2008 at 03:37:09PM -0700, Tim Bird wrote:
> With CONSOLE_TRANSLATIONS turned off, this saves about 6K
> on my kernel configured for an ARM development board (OMAP
> 5912 OSK).  In embedded products I'm familiar with,
> console translations are not needed.
>
> This was taken from the Linux-tiny project and updated slightly
> for 2.6.25.
>...

It seems to be always me who asks the controversial questions...:

Does the linux-tiny approach of adding a kconfig variable for each 5kB 
of code actually make sense? I'm asking since an exploding amount of 
kconfig variables and their interdependencies have a not so small 
maintainance impact in the long term.

And I'm wondering whether it's the best approach for reaching 
measurable results. E.g. my small patch that removed 
-maccumulate-outgoing-args on 32-bit x86 reduced the kernel size
there for the CONFIG_CC_OPTIMIZE_FOR_SIZE=y case by at about 2.5% (sic)
without adding any kconfig variables or #ifdef's.

Can you take a reasonable (best-case) .config for an existing device and 
get the following numbers:
- Ignoring patches that came from linux-tiny, by how many percent did 
  the size of the kernel increase or decrease between 2.6.16 and 2.6.26?
- By how many percent did the kernel size decrease due to patches from
  the linux-tiny project that added such kconfig options for a few kB 
  of code in the same timeframe?

My gut feeling is that the influence of this kind of linux-tiny patches 
is hardly noticably compared to the overall code size development, but 
if you have numbers that prove me wrong just point me to them and I'll 
stand corrected.

cu
Adrian

BTW: I'm not insisting on "between 2.6.16 and 2.6.26", that's just some
     timeframe big enough for showing general trends.

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/