Re: CONFIG_TINY

[Kent Borg <kentborg@borg.org>]

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.  

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.

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

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

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.


-kb, the Kent who thinks the language in which the kernel is written
should remain C and not drift toward being the config file.


P.S.  This reminds me of not littering the code with type defs that
reduce to simple types.  Abstraction for abstraction's sake seems
silly.  Keep it simple.