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

[Richard Kweskin]

On 29 Aug 2003 10:34:47 +0200
C David Rigby <cdrigby at 9online.fr> wrote:

> 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.

Thank you, David, for verifying that, indeed, some kernel sources "require" certain kernel config options.
 
> 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.

Here is a case of only being able to prove it cannot work (if a broken thing surfaces) but without many others also trying the same...
 
> 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?

Or even a selection of config files that *do* successfully compile with one or two different kernel sources so that we can download a minimum of stuff, compile on some local box and use the resulting kernel accordingly.
 
Richard


_______________________________________________
Rule Project HOME PAGE:  http://www.rule-project.org/en/
Rule Development Site:   http://savannah.gnu.org/projects/rule/
Rule-list at nongnu.org
http://mail.nongnu.org/mailman/listinfo/rule-list