[RULE] compiling kernels (sort of long...)

[C David Rigby]

Indeed, "cutting too much" often seems to be a problem.  It varies
depending on the kernel-source being used, as well.  As a concrete
example, I installed kernel-source-2.4.20-20.9.i386.rpm on my desktop
system and attempted to create a kernel for one of my notebooks which
does not have a PCI bus in it (it is in the testing farm as runaway, but
it now has only an 800MB hard drive).  Despite various adjustments of
this or that driver, I could never figure out how to successfully
compile a kernel using that source which DID NOT have PCI support. 
Compilation always failed if "PCI support" was turned off under "General
setup."  Being still relatively C-ignorant, I did not try to reason my
way through the kernel source to find out why this was the case.

On the other hand, the plain-vanilla linux-2.4.22 from www.kernel.org
happily compiled without PCI support.  So, some of RedHat's
optimizations of their kernel source seem to include the assumption of
PCI support in the kernel.  Of course, the tertiary version numbers of
the sources are different, so I can be accused of "comparing apples and
oranges."  But I would be surprised if such a small change in version
number led to such a significant change in the configuration of the
kernel.  Someone with more experience can certainly tell me how wrong I
am.

So after much trial-and-error, I have a functional, 486-optimized
vmlinuz-2.4.20-20.9custom kernel based on RedHat sources that is 667,677
bytes in size, and a functional, 486-optimized vmlinuz-2.4.22runaway
kernel based on vanilla sources that is 601,941 bytes in size.  The
difference is the existence of PCI support in the RedHat kernel.

This may seem like a lot of effort, but I think it is significant for a
machine with only 16MB of RAM.  The stock vmlinuz-2.4.20-8RULE kernel
for 386 and 486 machines is 1,183,221 bytes.

I will keep both kernels on the machine and experiment to see if I can
break any software as a result of using the vanilla sources.

Obviously this is moderately inefficient in the case where one is trying
to compile a kernel for someone that has unusual hardware, such as the
sbpcd CD-ROM that we discussed earlier.  Multiple iterations of compile
& test might be needed to get it right.  We may be better-served to
create a kernel + modules set for the slinky installer that can handle
every conceivable combination of older hardware.  If that ends up being
too large for a floppy disk, possibly an on-line repository of modules
would be a better solution?

On Mon, 2003-08-25 at 18:31, Richard Kweskin wrote:
> Hello All
> 
> Just to add here that I have compiled a kernel or two myself (when using the given config file) but have also gotten stuck trying to cut out too many bits while creating a different config file. My mania for making minimal things led to saying "no" to several options. However, the compilation would stop early during the make zImage stage and I always suspected that a kernel patched by Redhat (or any other distro) would require certain options to be compiled in to succeed.
> 
> On the other hand (I said to myself) if I take a plain vanilla kernel might I break some one(s) Redhat programs or components that require some patch or option.
> 
> Bottom line: point me in the right direction as to which kernel source to use and which config file to match with it and I can compile the beast.
> 
> Richard
> 
> 
> _______________________________________________
> Original home page of the RULE project: www.rule-project.org
> Original Rule Development Site http://savannah.gnu.org/projects/rule/> 
Original RULE mailing list: Rule-list at nongnu.org, hosted at http://mail.nongnu.org/mailman/listinfo/rule-list
> 



_______________________________________________
Original home page of the RULE project: www.rule-project.org
Original Rule Development Site http://savannah.gnu.org/projects/rule/
Original RULE mailing list: Rule-list at nongnu.org, hosted at http://mail.nongnu.org/mailman/listinfo/rule-list