Re: [PATCH 0/3] build system: section garbage collection for vmlinux

[Oleg Verych <olecom@flower.upol.cz>]

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
> 
> -- 
____