If having the source isn't enough flexibility for you, it's not possible TO
have enough flexibility for you.
The point of CONFIG_TINY is that anybody interested in looking at how to trim
the fat on their kernel has something to grep for, and it's als a quick and
dirty way to say "this kernel will go on boot floppy or eprom boot image"
without having to spend two days micro-managing.
Having "config_8_million_tweaks" is actually counter-productive. It's quite
possible to give people so many buttons and levers they can't find the two
they're interested in, and there will ALWAYS be instances where you have to
go diddle the source.
Are you seriously suggesting that every single #defined constant should be
editable from make menuconfig? If not, you acknowledge that there IS a line
that needs to be drawn. And the place it has CURRENTLY been drawn (what IS
in make menuconfig) is a darn good starting point for discussion of where it
should be.
> > 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.
More or less by definition, yes.
> This isn't
> really nice since to tweak most things you only need to change a few
> constants.
You're against people having to modify the source at all, then. That
argument's not going far around here, you realise this don't you?
> The problem is finding all of these constants, and the
> places where maybe someone used a number derrived from the constant, and
> so on..
1) This is a seperate argument. Your'e trying to bolt your personal pet
project on to the CONFIG_TINY discussion, and they have nothing to do with
each other.
2) Provide a patch. The CONFIG_TINY people have a patch. You do not. You
lose.
> > > 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..
Because you haven't personally done it, and nobody else seems to be
interested.
> > 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.
Let's not pretend having one config option for every #define in anything more
than a semantic difference as far as the #defines are concerned, and on top
of that it lowers the value of menuconfig by polluting it with stuff that
very few people should ever have to care about.
> Building a 'tiny' kernel should have nothing to do with any of this.
Oh good, we agree on something.
Start a new thread then, and stop objecting to CONFIG_TINY.
> Don't think 'tiny' think 'flexible'.
Nobody's working on CONFIG_FLEXIBLE. You're trying to hijack a project with a
different agenda because it doesn't do something totally unrelated that you
think should be done.
> 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.
And the universe in general should be easily manipulated by people who don't
understand how it actually works. This is called "magic".
> 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.
It should also have the ability to turn lead into gold and make people
younger. I don't think you'll find anybody who disagrees that these would be
great things for it to be able to do.
Rob
-- http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad, CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/