public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matt Porter <porter@cox.net>
To: Tom Rini <trini@kernel.crashing.org>
Cc: Mark Mielke <mark@mark.mielke.cc>, Adrian Bunk <bunk@fs.tum.de>,
	Rasmus Andersen <rasmus@jaquet.dk>,
	linux-kernel@vger.kernel.org
Subject: Re: CONFIG_TINY
Date: Thu, 31 Oct 2002 10:08:55 -0700	[thread overview]
Message-ID: <20021031100855.A3407@home.com> (raw)
In-Reply-To: <20021031143301.GC28191@opus.bloom.county>; from trini@kernel.crashing.org on Thu, Oct 31, 2002 at 07:33:01AM -0700

On Thu, Oct 31, 2002 at 07:33:01AM -0700, Tom Rini wrote:
> On Thu, Oct 31, 2002 at 12:33:10AM -0500, Mark Mielke wrote:
> > On Wed, Oct 30, 2002 at 06:10:02PM -0700, Tom Rini wrote:
> > > On Thu, Oct 31, 2002 at 01:53:14AM +0100, Adrian Bunk wrote:
> > > > could you try to use "-Os" instead of "-O2" as gcc optimization option
> > > > when CONFIG_TINY is enabled? Something like the following (completely
> > > > untested) patch:
> > > -Os can produce larger binaries, keep in mind.  If we're going to go
> > > this route, how about something generally useful, and allow for general
> > > optimization level / additional CFLAGS to be added.
> > 
> > Sure CFLAGS should be configurable, but CONFIG_TINY should always prefer
> > -Os over -O2. From 'man gcc':
> > 
> >        -Os Optimize for size.  -Os enables all -O2 optimizations that do not
> >            typically increase code size.  It also performs further optimiza-
> >            tions designed to reduce code size.
> > 
> > If gcc regularly generates larger code with -Os the answer is to talk to
> > the gcc people, not to avoid using -Os...
> 
> It's not that it does regularly, it's that it can, and if it does, it's
> not really a gcc bug from what I recall.  So I don't think CONFIG_TINY
> should prefer -Os over -O2 but instead we should just ask the user what
> level of optimization they want.  Remember, one of the real important
> parts of embedded systems is flexibility.

Thank you.  This is exactly why in the last CONFIG_TINY thread I made
it clear that a one-size-fits-all option is not all that helpful for
serious embedded systems designers.

Collecting these parameters in a single tweaks.h file and perhaps using
things like CONFIG_TINY, CONFIG_DESKTOP, CONFIG_FOO as profile selectors
into tweaks.h would be a lot more effective.  His collection of
(hopefully) size-optimizing tweaks can all be selected via CONFIG_TINY,
but have them collected at a single point like tweaks.h such that they
can be individually modified by an end system integrator.

Regards,
-- 
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

  parent reply	other threads:[~2002-10-31 16:36 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-30 22:36 CONFIG_TINY Rasmus Andersen
2002-10-30 23:48 ` CONFIG_TINY Rik van Riel
2002-10-31  0:53 ` CONFIG_TINY Adrian Bunk
2002-10-31  1:10   ` CONFIG_TINY Tom Rini
2002-10-31  5:33     ` CONFIG_TINY Mark Mielke
2002-10-31 14:33       ` CONFIG_TINY Tom Rini
2002-10-31 16:51         ` CONFIG_TINY Mark Mielke
2002-10-31 17:04           ` CONFIG_TINY Tom Rini
2002-10-31 17:12             ` CONFIG_TINY Mark Mielke
2002-10-31 17:24               ` CONFIG_TINY Tom Rini
2002-10-31 17:49                 ` CONFIG_TINY Sam Ravnborg
2002-10-31 18:11                   ` CONFIG_TINY Tom Rini
2002-11-01  2:09                 ` CONFIG_TINY Bill Davidsen
2002-11-01 14:12                   ` CONFIG_TINY Tom Rini
2002-10-31 18:26             ` CONFIG_TINY Kent Borg
2002-10-31 18:53               ` CONFIG_TINY Tom Rini
2002-11-04  2:13                 ` CONFIG_TINY Rob Landley
2002-11-04 19:50                   ` CONFIG_TINY Tom Rini
2002-11-04 20:34                     ` CONFIG_TINY Cort Dougan
2002-11-04 16:16                       ` CONFIG_TINY Rob Landley
2002-11-04 22:30                         ` CONFIG_TINY Eli Carter
2002-11-01  2:10             ` CONFIG_TINY Arnaldo Carvalho de Melo
2002-10-31 21:12           ` CONFIG_TINY Luc Van Oostenryck
2002-10-31 17:08         ` Matt Porter [this message]
2002-10-31 16:52           ` CONFIG_TINY Bernd Petrovitsch
2002-10-31 18:43             ` CONFIG_TINY Rasmus Andersen
2002-10-31 19:15               ` CONFIG_TINY Tom Rini
2002-10-31 19:27                 ` CONFIG_TINY Rasmus Andersen
2002-11-01 14:19                   ` CONFIG_TINY Tom Rini
2002-10-31 23:30               ` CONFIG_TINY Bernd Petrovitsch
2002-11-01  6:17                 ` CONFIG_TINY Rasmus Andersen
2002-11-01 22:05                   ` CONFIG_TINY Bernd Petrovitsch
2002-11-01 22:10                     ` CONFIG_TINY Rasmus Andersen
2002-11-01  2:03     ` CONFIG_TINY Bill Davidsen
2002-11-01 14:15       ` CONFIG_TINY Tom Rini
2002-11-04  2:13         ` CONFIG_TINY Rob Landley
2002-11-04 19:51           ` CONFIG_TINY Tom Rini
2002-11-04 16:09             ` CONFIG_TINY Rob Landley
2002-11-05 19:26             ` CONFIG_TINY Bill Davidsen
2002-11-05 19:56               ` CONFIG_TINY Tom Rini
2002-11-05 17:55                 ` CONFIG_TINY Rob Landley
2002-11-06  2:05                   ` CONFIG_TINY Tom Rini
2002-11-06 14:35                   ` CONFIG_TINY Bill Davidsen
2002-11-05 19:59               ` CONFIG_TINY Alan Cox
2002-10-31  8:24   ` CONFIG_TINY Rasmus Andersen
2002-10-31 10:05     ` CONFIG_TINY Erik Andersen
2002-10-31 10:08       ` CONFIG_TINY Rasmus Andersen
2002-10-31 11:08         ` CONFIG_TINY Erik Andersen
2002-10-31 19:33     ` CONFIG_TINY Daniel Egger
2002-10-31 19:55       ` CONFIG_TINY Rasmus Andersen
2002-10-31  8:32 ` CONFIG_TINY Jens Axboe
2002-10-31  8:53   ` CONFIG_TINY Rasmus Andersen

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=20021031100855.A3407@home.com \
    --to=porter@cox.net \
    --cc=bunk@fs.tum.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@mark.mielke.cc \
    --cc=rasmus@jaquet.dk \
    --cc=trini@kernel.crashing.org \
    /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