[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070906204349.GO475@flower.upol.cz>
Date: Thu, 6 Sep 2007 22:43:49 +0200
From: Oleg Verych <olecom@...wer.upol.cz>
To: Adrian Bunk <bunk@...nel.org>
Cc: Denys Vlasenko <vda.linux@...glemail.com>, sam@...nborg.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, Sep 06, 2007 at 02:21:43PM +0200, Adrian Bunk wrote:
[]
> > 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.
>
> There is no problem with his patch.
>
> His patch improves the build process.
I would like to know timing, btw. Size, especially shown 1%, doesn't
matter if link time increased dramatically. `Allyes' config, when i
had fast and rammish machine was terrible thing (last winter). If 32
cores/cpus is will of author, then i'm even more suspicious.
> And there's no reason to hide this from the users.
Patch? Did i said patch?
Ah, patch. Yes -- hide it, because it against LKML's rules. I can
provide ftp for such things, easily.
I said tool _and_ documentation. Because if developers don't know
about `static' code or _data_ and cann't find out that, then small
description is more than welcome, i think.
But, tool. Hide it also, becasue it's kind of thing to be shamed
of (:
== untested, for demonstation only ==
SED_REM='
/\.text\./s|\.text\.|.text_|g;
/\.data\./s|\.data\.|.data_|g;
/\.bss\.p/s|\.bss\.p|.bss_p|g; # for .bss.page_aligned only
'
for place in linux/arch/* linux/kernel linux/include/asm-*
do case $place
*cris) ADDON='/\.text\.__/n;' ;;
*powerpc) ADDON='/\.data\.rel/n;' ;;
*parisc) ADDON='/\.data\.vm[p0]/n;' ;;
*frv) ADDON='/\.bss\.stack/n;';;
esac
sed -i -e "$ADDON$SED_REM" `find $place -type f`
done
done
== ==
[]
> > > 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?
>
> There's nothing that requires treatment.
[Help for] The developers/contributors of those drivers, no?
> It's a matter of fact that the kernel takes advantages from some
> features of GNU binutils and GNU gcc that might not be available
> in other versions of these tools.
>
> Whether you like it or not - that's not going to change.
I don't like fast, one-sided solutions.
> But don't continue arguing about something where you won't win with
> words - it's open source, so you can always create a fork of the Linux
> kernel that builds with whatever toolchain you want.
I just want to have review process to be real not only in C hacking.
> The only way you could convince other people from your point of view
> would be if your forked version of the kernel would contain advantages
> that convince many users to use your kernel rather than Linus' one.
>
> cu
> Adrian
>
> --
____
-
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