Messages in this thread | | | From | Rick Hohensee <> | Subject | Re: Kernel autosetup script | Date | Mon, 5 Jul 1999 01:51:29 -0400 (EDT) |
| |
Riley Williams... >Hi there. > >There's been enough aggro regarding an autocompile script to last a >lifetime, but nobody seems to have addressed the real need, which >IMHO is a script that deals with the full process, starting with >"I've extracted the kernel tarball into this directory" and finishing >with "Good, I'm now using that kernel" - what I refer to as an >autosetup script. > >Here's how I'd like to see any autosetup script working: > > 1. Ask the user whether we are compiling for the system we are > running on, or a different system. >
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/
| |