public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@kernel.org>
To: Oleg Verych <olecom@flower.upol.cz>
Cc: Denys Vlasenko <vda.linux@googlemail.com>,
	sam@ravnborg.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] build system: section garbage collection for vmlinux
Date: Thu, 6 Sep 2007 14:21:43 +0200	[thread overview]
Message-ID: <20070906122143.GM16016@stusta.de> (raw)
In-Reply-To: <20070906114044.GM475@flower.upol.cz>

On Thu, Sep 06, 2007 at 01:40:44PM +0200, Oleg Verych wrote:
> On Thu, Sep 06, 2007 at 11:55:46AM +0100, Denys Vlasenko wrote:
> []
> > > Give me example, please, why function must be non static if not used.
> > 
> > Where do you see I'm saying that they must be non-static?
> > I'm all for marking functions static. I just did it for aic7xxx.
> > 
> > > If usage requires kconfig tuning, then this is a better way to go,
> > 
> > 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.

There is no problem with his patch.

His patch improves the build process.

And there's no reason to hide this from the users.

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

There's nothing that requires treatment.

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.

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.

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

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2007-09-06 12:21 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-05 13:43 [PATCH 0/3] build system: section garbage collection for vmlinux Denys Vlasenko
2007-09-05 13:47 ` [PATCH 1/3] " Denys Vlasenko
2007-09-05 13:49   ` [PATCH 2/3] " Denys Vlasenko
2007-09-05 13:55     ` [PATCH 3/3] " Denys Vlasenko
2007-09-05 18:40       ` Denys Vlasenko
2007-09-05 20:46         ` Sam Ravnborg
2007-09-06 10:55           ` Denys Vlasenko
2007-09-06 22:33             ` Sam Ravnborg
2007-09-10 12:01             ` Sam Ravnborg
2007-09-10 19:02               ` Denys Vlasenko
2007-09-10 19:14                 ` Sam Ravnborg
2007-09-11 11:23                   ` Denys Vlasenko
2007-09-11 11:55                     ` Sam Ravnborg
2007-09-05 20:07   ` [PATCH 1/3] " Sam Ravnborg
2007-09-06 10:59     ` Denys Vlasenko
2007-09-06 22:36       ` Sam Ravnborg
2007-09-08 15:02     ` Denys Vlasenko
2007-09-05 15:53 ` [PATCH 0/3] " Oleg Verych
2007-09-05 18:46   ` Denys Vlasenko
2007-09-05 20:34     ` Oleg Verych
2007-09-05 21:52       ` Adrian Bunk
2007-09-06 10:55       ` Denys Vlasenko
2007-09-06 11:40         ` Oleg Verych
2007-09-06 12:21           ` Adrian Bunk [this message]
2007-09-06 20:43             ` Oleg Verych
2007-09-06 20:39               ` Adrian Bunk
2007-09-06 21:16                 ` Oleg Verych
2007-09-06 21:19                   ` Adrian Bunk
2007-09-06 22:01                     ` Oleg Verych
2007-09-06 22:43                       ` Adrian Bunk
2007-09-06 12:33           ` Denys Vlasenko
2007-09-05 16:29 ` Daniel Walker
2007-09-05 18:37   ` Denys Vlasenko
2007-09-05 18:38     ` Daniel Walker
2007-09-05 19:14       ` Denys Vlasenko
2007-09-05 19:07         ` Daniel Walker
2007-09-05 19:49           ` Denys Vlasenko
2007-09-05 19:46             ` Daniel Walker
2007-09-06 10:57               ` Denys Vlasenko
2007-09-06 15:13                 ` Daniel Walker
2007-09-06 17:07                   ` Denys Vlasenko
2007-09-07 16:31                     ` Daniel Walker
2007-09-07 17:24                       ` Sam Ravnborg
2007-09-07 17:19                         ` Daniel Walker
2007-09-07 17:30                       ` Denys Vlasenko
2007-09-07 17:38                         ` Daniel Walker
2007-09-05 19:31         ` Adrian Bunk
2007-09-05 19:24           ` Daniel Walker
2007-09-05 19:46             ` Adrian Bunk
2007-09-05 19:27 ` Adrian Bunk

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=20070906122143.GM16016@stusta.de \
    --to=bunk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olecom@flower.upol.cz \
    --cc=sam@ravnborg.org \
    --cc=vda.linux@googlemail.com \
    /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