>>> I wanted to do it this way: compile -> check for 'kernel to big'
>>> -> recompile The question is: which steps do I have to repeat:
>>> dep ? clean ? I don't think so but is there anyone who could
>>> confirm this FOR SURE ?
>> All the patch does is to move tools/build from the very end of the
>> dependancy listings to immediately after the beginning thereof, so
>> it should be impossible for it to cause any problems.
>> The result of that patch is to guarantee that (A) all items
>> compiled by both "make zImage" and "make bzImage" are compiled
>> before any of the items unique to that method, and (B)
>> tools/build is the last common item to be compiled in both
>> cases. This allows the existence or otherwise of tools/build to
>> be used to determine whether the fault was in the common items
>> or not, if compilation failed.
> They only reason I know so far that compilation could fail for
> zImage and NOT for bzImage is that the kernel gets to big.
I've had zImage fail and bzImage not fail due to a problem with the
setup dependancy that wasn't there with the bsetup dependancy. The
root cause was that the kernel was too big, but it hit in a different
place, and didn't produce the "Kernel is too big" message as a result.
> So, if 'make zImage' fails and there is no message 'kernel to
> big' it should be in the 'common part', right ? So I think it's
> much easier to use the log file that I've saved anyway and look
> for this message: 'kernel too big'.
An even easier way would be to simply do the "make bzImage" if the
"make zImage" failed, and that would have the advantage over your
method of never failing to run "make bzImage" when it needs to be
run...
> The advantage for this is:
> - don't need a patch for the Makefile (VERY IMPORTANT, think of
> newcomers)
The patch could go in anyway, as it doesn't affect anything else...
> - don't need to know so much about what really happens during
> make (b)zImage and
> - you are not affected by any changes
> Disadvantages:
> - mkkrl is lost when someone find the message 'kernel too big'
> boring and replaces it with 'kernel IS too big'
> - if someone gives a message with 'kernel too big' in it mkkrl
> mistakes this as our bzImage flag
> But I think it's ok.
It could be...
>> Given that, the following script has worked reliably for me...
>> 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...
>> Q> rm -f arch/i386/tools/build
>> Q> make zImage
>> Q> if [ -f arch/i386/tools/build -a ! -f arch/i386/boot/zImage ]; then
>> Q> make bzImage
>> Q> fi
>> Does that answer your question?
> 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.
In fact, if you analyse that carefully, you will note that the
following logic is correct by definition:
Q> #!/bin/bash
Q> cd /usr/src/linux
Q> if [ .config -nt .depend ]; then
Q> make dep clean
Q> fi
In other words, that part of the procedure only needs doing if .config
is not older than .depend (both being in the /usr/src/linux directory).
Your script may wish to take advantage of that fact...
>>> By the way, I was thinking of a database or something that makes
>>> the whole building process inclusive configuration a little bit
>>> easier. E.g. storeing the name of the hardware component that
>>> this feature is for. Like this many options could just be hidden
>>> and everything would be so much easier. But it's a lot of work
>>> ... and I've got so little time ...
>> Note that there are two types of scenario that any setup script will
>> need to deal with...
>> 1. Compiling on the system it is to be run on.
>> 2. Compiling on a different system to the one it is to be run on.
>> In the first type of scenario, it should be possible for most of
>> the configuration to be done automatically, but in the second,
>> there is probably little that can be done without user assistance.
> I haven't thought of the 2nd. You are right, but still ... for
> people who just want to get a lean kernel it could be easier ...
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...
> 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...
One other thought - is your script going to be i386 only?
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
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/