Re: modules problems
>> Unresolved Issues (IMHO)
> 1. What exactly happens with 'make modules' and 'make
> modules_install'? Can someone describe the algorithm, or at least the
> 2. Should 'make modules' and 'make modules_install' *precede* or
> *follow* the kernel-building 'make zlilo' (or 'zImage' or 'zdisk')?
> 3. Are there instances when 'make modules' and 'make modules_install'
> should *not* be used?
> 4. What are the appropriate settings, *and why*, for
> I certainly understand if people are tired of talking about modules,
> so my apologies to the exasperated. I will be happy to continue
> discussion by private email, but for now it seems to me that the list
> is still the best place for this discussion.
make modules goes through the entire make process and generates object
files for each *.c file which has been designated to be made into a
module. In kernel version 1.2.13 and on into 1.3.xx (I am not how sure
at what xx a change was made), almost all modules to which you answered
no in making the configuration file are automatically selected to be
made into modules. In later versions of kernel 1.3.xx, m was added to
the possible answers for making the configuration file (i.e., y, m, n).
Then only those answered with m will be made into modules. There is one
exception to this in the case of later versions of ppp. Later versions
of ppp automatically select bsd_comp (a compression program) to be made
into a module.
make modules_install moves all of the generated modules (i.e., the *.o)
programs into various directories under /lib/modules/<kernel_version>/.
<kernel_version> would be 1.2.13 or whatever. A file modules.dep is
also generated in this directory (but not by make modules_install, I
believe) that shows dependencies of the modules, e.g., ppp.o requres