From: Tom Rini <trini@kernel.crashing.org>
To: Kent Borg <kentborg@borg.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 11:53:08 -0700 [thread overview]
Message-ID: <20021031185308.GE30193@opus.bloom.county> (raw)
In-Reply-To: <20021031132607.E21801@borg.org>
On Thu, Oct 31, 2002 at 01:26:07PM -0500, Kent Borg wrote:
> On Thu, Oct 31, 2002 at 10:04:20AM -0700, Tom Rini wrote:
> > In other words, s/CONFIG_TINY/CONFIG_FINE_TUNE, and ask about
> > anything / everything which might want to be tuned up.
>
> Please, no. Keep this simple.
We can keep it simple, as long as we keep it flexible.
> I don't want a bunch of configs that abstract out everything I might
> want to tamper with to make a small system. The only way I am going
> to make sense out of them will be to look at the source controlled by
> each anyway. I would rather search the source for CONFIG_TINY and see
> a single, coherent, and sensible set of concrete changes that make
> things smaller. Let me mangle and customize from there, it will be
> much easier for me to understand what I am doing.
Templates would help out here. Right now, if something isn't a config
option, you have to dig into the source to tune things. This isn't
really nice since to tweak most things you only need to change a few
constants. The problem is finding all of these constants, and the
places where maybe someone used a number derrived from the constant, and
so on..
> > Then this becomes a truely useful set of options, since as Alan
> > pointed out in one of the earlier CONFIG_TINY threads, his Athlon
> > could benefit from some of these 'tiny' options too.
>
> Certainly, if there are potential config options that would be truly
> useful to general folks, then by all means, yes!, make them separate
> options. (Isn't that what has been going on all along?)
I would hope it was, but it doesn't seem like that's been what's going
on..
> But let us
> not put in a config for every imaginable tuning and then pretend that
> hiding them behind a CONFIG_FINE_TUNE somehow doesn't make them any
> less a groady mess.
Let's not pretend that changing > 1 tunable param with 1 CONFIG question
makes it any better than it is now.
> Isn't there an attempt with the current config process to set up
> dependencies so that any config from "make config" or "make xconfig"
> has a crack at being at least self-consistent, if not otherwise
> sensible? Won't this CONFIG_FINE_TUNE become a bloating ground for
> every obscure special interest config, related to size or not, whether
> it builds or not, whether it runs of not? (And be so confusing as to
> still not help me build a tiny kernel?)
Building a 'tiny' kernel should have nothing to do with any of this.
Don't think 'tiny' think 'flexible'. And I'm not necessarily saying it
has to be N CONFIG options (Matt Porter's template idea is rather
tempting), just that things have to be:
a) Flexible enough such that someone who wants to tweak param X doesn't
have to know every intricate detail of subsystem Y just to tune things.
b) Done in a way that doesn't clutter up the code in question (ideally
s/some_constant/SOME_DEFINE).
c) Be simple enough such that people don't shoot their feet off, at
least not unintentionally.
> If something is worth a config, give it a config. (And if it isn't,
> don't!) But not every component of making a tiny system is worth a
> standalone config. Let me grep for CONFIG_TINY and hack my
> nonstandard things from there.
By that token, if it's not worth it's own CONFIG, don't mask it under 1
CONFIG either. That doesn't make it easier to tune one param if you
have to check N occurances of CONFIG_TINY to make sure you got all of
the correct places.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
next prev parent reply other threads:[~2002-10-31 18:47 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 ` Tom Rini [this message]
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 ` CONFIG_TINY Matt Porter
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=20021031185308.GE30193@opus.bloom.county \
--to=trini@kernel.crashing.org \
--cc=bunk@fs.tum.de \
--cc=kentborg@borg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@mark.mielke.cc \
--cc=rasmus@jaquet.dk \
/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