From: "Oleg Verych" <olecom@gmail.com>
To: linux-embedded <linux-embedded@vger.kernel.org>,
linux-kbuild@vger.kernel.org
Subject: about size optimizations (Re: Not as much ccache win as I expected)
Date: Fri, 13 Jun 2008 22:52:52 +0100 [thread overview]
Message-ID: <8499950a0806131452j5dc9574dk336e9e06ee9e1785@mail.gmail.com> (raw)
>> And what kinds of source/kconfig changes are made for every build?
>
> I start with a baseline config for an embedded board, then
> alter, one at a time, individual config items related to kernel size.
> No source changes are made.
Using same `gcc -E` principle, I once had a dream to create
build with something like "whole-kernel-at-time" optimising
compiler option:
for file in $all_core_files
do gcc $opt -E $file >>core_kernel.c
done && gcc $opt code_kernel.c -o vmlinux.c.o
# same for some special parts and asm
do_foo
# do final link
do_vmlinux
I've had something like that once for `dash` and had few
percents of size reduction. It would be interesting to
implement and check this in linux.
Also i've many things to point-tune/point-remove based on
usage patterns/source patterns, which can be easily removed by
stream text editor from sources. These like not needed
* syscalls,sysctl, ioctls
* fields in data structures/sources for handling them
* code branches or code blocks which are known (in particular
board / embedded case) to be useless etc. etc.
But all this requires non trivial source text editor or visual tools
for easy analysis, navigation, marking, RE generation and
build + run testing.
With mid-70 command line and `make` (even kbuild version)
or 20++ years old technology of text editors, it's not that trivial
to accomplish.
Some kind of IDE for kernel development is needed. Here
one will have all whitespace and code style policy, static
checks for stupid security holes, C mis-use, kernel API
mis-use, all those crutches in linux/scripts/* in one place
and applied right away.
Sorry, for this rant, but i see no developemnt here at all.
New schedulers, slab allocators, file systems are great.
But all this has nothing to do with fundamental developent
of the tools. Hardware is quite fast and have pretty much
of RAM/ROM/caches now, yet software just bloats.
The streaming, pre-cc text editing is the key, fine GCC is not.
--
sed 'sed && sh + olecom = love' << ''
-o--=O`C
#oo'L O
<___=E M
next reply other threads:[~2008-06-13 21:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-13 21:52 Oleg Verych [this message]
2008-06-14 7:43 ` about size optimizations (Re: Not as much ccache win as I expected) David Woodhouse
2008-06-14 9:48 ` Adrian Bunk
2008-06-14 9:56 ` Oleg Verych
2008-06-14 10:05 ` David Woodhouse
2008-06-14 10:27 ` Oleg Verych
2008-06-15 16:00 ` Jamie Lokier
2008-06-15 16:56 ` Oleg Verych
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8499950a0806131452j5dc9574dk336e9e06ee9e1785@mail.gmail.com \
--to=olecom@gmail.com \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).