[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: modules vs. device drivers: Act 2



Udi Finkelstein writes:

 > Ok, after everyone has been saying that modules are completely independent of
 > the kernel, I'm still skeptical for the following reasons:
 > 
 > 1. Why does each module has 3 options (built-in/module/none) in the kernel's
 >    .config file? 2 options should have been enough, as module==none.

If an option is set to module the piece of code is built as a module.
If it's set to none it's not built at all. Seems pretty much
obvious...

 > 2. How is the binding between major/minor device numbers and modules work?

The module loader (either kerneld for 2.0.x or kmod for 2.1.x) has
ready mappings for some of the numbers. For those that can have one of 
many drivers loaded for them (such as the SCSI devices - they must
know *which* SCSI driver to load in order to enable SCSI!), you use
the /etc/conf.modules file, like this:
alias char-major-14 sb
This tells kerneld/kmod that requests on char major 14 should autoload 
the sb module, because that's the sound card that I have.

BTW, you could find all this information in the Kerneld mini-HOWTO.
You might want to look there.

 > But the most convincing test was very simple:
 > 
 > I have recompiled my 2.0.34 kernel with AHA152X as module. 2 minutes and 40
 > seconds later (boy, this overclocked Celeron 300A is FAST!) I have saved down
 > the resulting kernel.
 > 
 > After that, I have commented out the AHA152X flag out of the .config file, and
 > built the kernel again.
 > 
 > Guess what - I got two different kernels.
 > 
 > If modules are COMPLETELY INDEPENDENT of the kernel, how did I get 2
 > **different** kernel images??

One possible reason might be that the kernel stores the time at which
it was compiled. If the kernels were the same size but with different
contents, this might be the reason. If the size is different too, that 
might be due to compression (since the image changed it might have
been compressed better/worse).

 > Since the kernel is gzip'ed but unfortunately has an uncompressed bootstrap
 > code, preventing the use of gunzip on it, I can't really do something like:
 > gzip -d zImage | strings | grep aha152x
 > to prove the kernel has hooks for the aha152x module.
 > 
 > anyone care to explain?
 > 
 > n.b. back in the 1.x days, I remember it was possible to build an uncompressed
 > kernel image. Is this still possible? even if I can't boot it, I can still run
 > "strings" on it.

I believe that the /usr/src/linux/vmlinux file is what you're looking
for. It's always created when you compile a kernel.


--
Alex Shnitman
alexsh@linux.org.il   UIN 188956
http://alexsh.home.ml.org  --  PGP key here
http://www.debian.org  --  and the OS here