Step one is extract the kernel tarball, because the script is ostensibly
in the main kernel source tarball. Already the script can't handle it's
proposed purpose in the default case by itself. OK, give a launch script
out, that looks for the main script in the top dir of the kernel sources.
Distributors should include such launch script. I'd welcome it.
/sbin/kernel maybe. So step one now is launch the real script. If that
fails tell the user how to get kernel source, and or where to put it, or
ask them "shall I fetch it?"
After the above succeeds I guess we come to your step 1. We know we have
source. We assume we have the tools. We're running a script, after all.
The default should have no dependancies make config doesn't have.
Well, I guess make menuconfig's dependancy on awk is acceptable.
The dependancies of these kinds of things is my pet peeve, not that they
are not "metascopic" enough.
OK, step 1.orig, ask the user if this build is for this box. If no, do
they want to clone the source tree? Do they keep a source tree for each
platform they deal with on this box? If so, do we want to tell them what
the previous build(s) were? Is this a cross-architecture-compile? (hooo
boy)
The design considerations are exploding, and we haven't gotten to...
"determine the hardware using a kernel that probably doesn't know about
all the hardware because that's why you're doing a re-build" yet, much
less "what is the state of the source tree?" and "modules too?". This is
the fatal frailty of all-in-one top-down "solutions". For something like
this, count me out. You either break most of the time, or make radical
narrowings of options, and/or the bloat is terrible. You might then make a
bundle on support, until your client base migrates to something that
works.
I have a few bottom-up suggestions...
Docs. explain what tends to work in what scenario. I personally
find that make mrproper is required after many patches, but that make dep
may suffice after a minor re-config. (BTW, would someone like to comment
on why normal C/cpp dependancy processing is inadequate and why make dep
exists?) The docs on this may exist; I haven't looked at the Kernel-HOWTO
in a while. The general problem with docs in Linux/GNU/unix/your_name_here
is making the user aware that the docs exist.
make config should do menus, or flow control that reflects user
choices. Since when are ncurses and awk necessary for a sh case statement?
Every make config option "?" entry should have an x86 example
size, at least as a guess. This is not code, it doesn't have to be exact.
This is also very easy.
Default .config . You mention that. Defaults are simple and
valuable. The default should support lots of stuff pursuant to booting.
Large is OK here. Honestly, I don't know that a clean source tree isn't
defaulted. On a nearby chat window I'm told it isn't. If a default
existed, Linus' personal box is hardly the least common denominator.
Perhaps the problem here is that this is an extra and uninteresting step
for Linus himself. Linus, this is a cheap win.
I imagine there are kernel source maintenance techniques in use by
the readers of this list that are several orders of magnitude more
sophisticated than mine, but in this context I'm a mere plain user, so
perhaps some things bear mention. I have a kernel/2.2/built directory
for previous images and System.maps and so on. When I build a kernel I do
grep -v "#" .config >> arch/i386/boot/bzImage
and possibly also echo or cat some notes onto the end of the image.
start_here. Not a do-all-for-everyone script, but a simple little
dohicky that tells the user about make * , asks them if they want to
read Kernel-HOWTO and so on. I guess in the sense of a need for a clear
starting point, we agree.
Don't include any of this newbie stuff in a dev series. Include a
"are you sure you have the right kernel?" version of start_here.
prepend a 0 to dev series kernel #'s, e.g.
0.2.3.22-it's_SUPPOSED_to_be_broken,_MORON
Last time I looked at the config scripts, there was stuff for make
menuconfig that make config had to work around, IIRC. That's broke, from a
maintenance point of view. That which has least dependancies should be
allowed to stay that way. If there's a conflict, the resolution is the
problem of the fancier version, not the simpler.
The Documentation/Changes file could stand to be made a little
more prominent somehow, particularly around major-version-release time.
These are just various discrete ideas. They all work independant of each
other, in almost all scenarios. There's a nice thing about sound
bottom-up practice. It sometimes makes the top-down stuff possible. Look
at all the things Linus has made possible by valiantly, constantly fending
off the bletchery people want to saddle his sound base with. He seems to
spend a big portion of his time these days preventing complexity, and has
stated the importance of simplicity quite clearly recently.
Bottom line: as far as "build the kernel I want", the bottom-up is still
awful shakey for the top-down you desire.
Rick Hohensee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/