Re: 1.3.57 module loading problems
Ehh. Hi again!
>
> Well, Lauri T. has a solution, but it doesn't help me understand making
> modules work. If I compile the kernel with no module support, it boots up
> and ppp works. However, during boot up, messages about "can't load module
> ..." continue to be reported (I assume that's because I have a
> /etc/modules file, which I need to leave installed so I can use the other
> kernel) This isn't a problem because everything works.
Hmm. I think that there is something somewhere in the boot-up scripts that
either is called "modprobe" or "depmod" that looks in ALL the directories
/lib/modules/*/ and checks that there are no unsolved references. However,
a "make modules" or "make modules_install" (or whatever the make targets are,
bad memory) do not remove any old modules. So if you once had the module eata.o
(in /lib/modules/scsi) it's still there. Thus this depmod or modprobe program
finds it and checks for unresolved references. After this program is run, the
boot-up script continues with doing an insmod for every module that is listed
in some configuration file (/etc/modules, perhaps?). The sum of all this
is that it is possible to receive warnings about unresolved references,
although the module generating the warnings is never considered to be loaded.
I hope I know what I'm talking about. Please correct me if somebody finds any
errors in this message.
>
> Before I tried this I tried Michael D's solution. I did a make mrproper,
> followed by the rest, with no better results. I did choose both "module
> support" and "kernel symbol whatever" options both times and get the same
> result. Memory says that the first time I built this kernel I did
> everyting but the make modules_install and the kernel worked even though
> it complained about the "unsatisfied symbol reference". I can only guess
> that, instead of installing modules properly "make module_install" breaks
> things even worse.
>
> My main reason for finding modules attractive has to do with other new
> users problems installing Debian on small machines (4meg) with special
> scsi or ethernet cards. Currently the method involves including every
> possible driver in the kernel. This makes a big kernel, that, when
> coupled with a ramdisk and buffers, tend to blow 4 meg machines out of
> the water. Being able to choose at installation time, just the modules
> that support your hardware will make these kinds of installs possible.
>
> In addition modules are modular. I know this sounds redundant, but
> modularity issues are hard to inforce on a group project. Forcing drivers
> to fit into modules helps to inforce the modularity issues that reduce
> and localize bugs in the most recently modified module.
Right on.
>
> The other time modules are useful, are in those machines that are always
> loosing or gaining various hardware controlers, like scsi controlers,
> ethernet cards and such.
>
> Lauri T. is the second person to describe modules as a "collection of
> bugs". To me, this just means that it needs to be FIXED!
Well, I looked at the code, and my first impression is it's messy.
Yes. Let's fix it! I. e. the module mess.
I'm interested in talking about how modules should work and what kind of
interface there should be. If we arrive at an sensible and feasable solution
I might even find time to code (some of) it. However I'm quit busy at work,
so my replies won't come quickly.
>
> Thanks for all the helpful suggestions. I really do appreciate it, even
> though I feel nothing has been resolved.
>
> Thanks for all the help,
>
> Dwarf
>
> ------------ --------------
>
> aka Dale Scheetz Phone: 1 (904) 877-0257
> Flexible Software Fax: NONE
> Black Creek Critters e-mail: dwarf@polaris.net
>
> ------------ If you don't see what you want, just ask --------------
>
>
Bang the drum,
MartinS
Reply to: