Kernel rebuild reveals author's limited understanding of loadable module subsystem

Hi Folks,

I have a Dell Inspiron 3700 notebook that has been gathering dust for a couple
of years and I decided this was the time to redeploy it as a Linux desktop.  I
installed Red Hat 9.0 and it worked very well.

I also have an ImageMate flash card reader than connects via USB and
apparently presents each of two slots as a SCSI device.  Initially I could
only see one slot and with some diligence I learned that there is a kernel
configuration parameter -- CONFIG_SCSI_MULTI_LUN which needs to be set to "y"
and the kernel needs to be rebuilt.

First question: Is there no runtime parameter I can pass to the kernel to
accomplish this? (... he asks hopefully)

So, I started down the rebuild road.  It was something I was interested to try
anyway.  My first question was the configuration for my running system and I
learned that the RedHat distro saves that in /boot/config-2.3.20-6 and I can
"make oldconfig" and xconfig from that to get the new .config file.  So far,
so good.  Since my change was to trivial, I concluded that I shouldn't have to
rebuild the modules -- in fact, I thought I could simply rebuild the kernel
with the same version number, save it with a different file name, save the
associated System.map, create a grub stanza and, that should be that.

Second question: Shouldn't I have been able to do this?  I saw instability
from unknown origins and I concluded that it must be my hacked kernel.  It's
not clear if there was something wrong with my theory or my procedure.  If the
theory is wrong, then the procedure is moot, so the question is in theory.
(Unexplained mystery: the new kernel with the additional feature is 100 bytes
SMALLER ?!?  This caused no end of re-examination of my procedure.)

Ultimately I concluded that the best way out of this was to rebuilt a new
custom version of the kernel 2.4.20-6a, which I did -- including modules.

Third question: The /lib/module trees seems to have slight differences between
them -- most notably the location of the pcmcia directory.  I didn't
exhaustively compare the trees.  Does this indicate presence of changes in my
new kernel that I didn't intend?

Finally, the new kernel does exactly what it is supposed to do for the
ImageMate -- presents it as two SCSI disks and it is stable.  However, the
pcmcia stuff doesn't work.  On boot pcmcia_core is not locatable, but as the
first order of business I can /sbin/modprobe pcmcia_core and there is no
problem.  I've removed the module.* files and reconstructed them with depmod
(which ALSO happens on boot with RedHat) but this boot problem persists.  The
nature of the problem is that it is quite reproducible and I haven't found
anything that changes the behavior.  My experience with loadable modules
during boot is still pretty light.

Fourth question: I'm interested to learn much more about the entire loadable
module subsystem.  I think I should be able to debug a silly little
configuration problem like this, but I'm not finding any design documents.
Any ideas?


Chris.

Life is a journey, not a destination ...
_______________________________________________
LinuxManagers mailing list - http://www.linuxmanagers.org
submissions: LinuxManagers-35TzE1X9F6582KRnZfj+bdi2O/[email protected]
subscribe/unsubscribe: http://www.linuxmanagers.org/mailman/listinfo/linuxmanagers