[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200709061333.48084.vda.linux@googlemail.com>
Date: Thu, 6 Sep 2007 13:33:47 +0100
From: Denys Vlasenko <vda.linux@...glemail.com>
To: Oleg Verych <olecom@...wer.upol.cz>
Cc: sam@...nborg.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thursday 06 September 2007 12:40, Oleg Verych wrote:
> On Thu, Sep 06, 2007 at 11:55:46AM +0100, Denys Vlasenko wrote:
> > We already do it, but we don't have enough developers to audit
> > every driver for every possible combination of config options.
> > As a result, there always be some amount of unused functions and data.
> > Using --gc-sections will discard that.
>
> You've did a tool. Documenting this tool to have it available for
> testers/janitors/maintainers is a better way, than to have all that
> opinions/problems with merging-to-mainline.
>
> > > than to adopt yet another GNU/Luxury.
> >
> > Actually, this is how linkers should have worked long ago.
> > Borland's Turbo Pascal was doing it ten+ years ago.
> >
> > I don't understand why you are opposed to toolchain helping
> > humans to get optimized result. But it's fine with me.
> > I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS.
>
> That's why. It's treating symptoms, isn't it?
If I understand you correctly, you seem to think that this work
of identifying every piece of code which can end up unused under
specific combination of CONFIGs, and #ifdef'ing it out,
should be done by people, not machines.
I disagree.
Allyesconfig kernel has ~1700 unused functions/data objects,
and it is only *one* of possible .configs.
There is more than 2900 CONFIG options in kernel, giving you
about 3^2000 possible permutations.
If you find it interesting to work on making them
to not have unused functions, more power to you,
and good luck convincing people to accept tons
of additional #ifdefs.
--
vda
-
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/
Powered by blists - more mailing lists