Okay, there where some good ideas about all the zImage and bzImage stuff
and I'll try to extend my script with all this in my mind and than all
of you can have look at it, test it and say me what you think of it.
Riley Williams wrote:
> [...]
> >> Q> if grep CONFIG_MODULES .config | grep '=y' > /dev/null ; then
> >> Q> make modules modules_install
> >> Q> fi
>
> > This might be a good idea, I haven't thought of people not using
> > modules.
>
> Try doing the "make modules" with modules disabled, and you soon
> discover that it reports an error...
So, it should get in definitely.
> [...]
> > Yes and no. Looking at your script I can see that you assume
> > that you don't need to (re)make a dep and clean as you don't use
> > it after zImage fails.
>
> > But my question was to be accurate: Is there ANY case that
> > zImage fails with 'kernel too big' where you should do a 'make
> > dep' or 'make clean' before 'make bzImage' ?
>
> To answer that, let's look at what "make dep" and "make clean" do...
>
> 1. "make dep" goes through the source files and determines the
> dependancies that exist when compiled for a given configuration.
> Therefore, this step ONLY needs doing if the configuration has
> been changed since it was last done.
>
> 2. "make clean" goes through the kernel source tree and removes all
> of the files produced as a by-product of compilation, as they may
> have been produced based on incorrect dependancy information. It
> therefore only needs doing if "make dep" has been done since it
> was last done.
Thanks. Question answered.
> [...]
> I have recently set up several different 386dx/{16,20,25} based
> systems as print servers and inter-network-segment gateways for a
> school, and I would hate to compile a modern Linux kernel on one of
> those systems.
>
> Perhaps the script could be split into two parts, one to run on the
> target system to determine the required configuration, and one to run
> on the compilation system to control the compilation process - and
> which, if used in mode 2, produces a tarball ready to be extracted on
> the target system that drops the modules in the relevant directory and
> puts the kernel image in its relevant directory...
Yes. That's a possibility. But, the first is to get this working on the
same computer. To name it:
1. find a way to determine as much as possible about the current
hardware.
2. find some questions that are easy to answer and completes the
knowledge about the hardware.
3. sort all options by the criteria: MUST SET, MUST NOT SET, MAYBE SET.
4. Let the user choose options that MAYBE SET.
5. You've got your configuration.
>
> > E.g.: I wanted to use my SB PCI 64V sound card and I'm STILL not
> > sure which options I have to set. There are so many
> > contradicting statements in the internet.
>
> The big problem with that idea is keeping the database up to date,
> unless you plan on buying one of every different card that comes
> out...
I was thinking of a database which many people maintain. For example:
one person finds out no matter how which settings he needs for his new
component X and he fills out a template provided that generates an email
which will be a new entry in the database.
Okay, but all that is in the future. First of all I want to do it in the
simple way: Starting to work after xconfig. If that is finished I would
like to extend it in this direction.
>
> One other thought - is your script going to be i386 only?
> [...]
No, as long as there is no real good reason for that I want to keep it
generic.
Best wishes,
Steffen
-
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/