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

Oleg Verych
2007-09-06T20:28:51Z

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