Beware of dragons in module loader code!

Peter Wemm peter at
Sun May 16 18:36:21 PDT 2004

I've committed the support changes and enabled the new module loader, 
but beware!  It does still blow up!  Consequently, I did *NOT* remove 
the 'NO_MODULES' override in GENERIC etc because there are a number of 
system daemons that will try and load things during startup.  If this 
suddenly started loading modules, it Would Be A Bad Thing.

On an unrelated note, I could really use some eyes looking at the 
sys/kern/link_elf_obj.c file.  Somewhere, I have a bug (or a series of 
bugs) that is causing significant memory trashing.  Yes, it is hairy 
code, but the kind of thing that is likely to be wrong include:
- using the wrong limit for an array.  eg: nrel for nrela[] arrays or 
vice versa.
- index scale bugs.. eg: adding or multiplying by sizeof() instead of 
the indexes.
- size scaling bugs.  eg: mallocing an array without multiplying by 
- something really messed up. :-)

But, in spite of all this, it does successfully load modules and they do 
run.  The problem is that later on, the system objects to its memory 
having been trashed in the past.  In other words, its quite useless 
except perhaps for simple load/unload driver tests where the test 
module is compiled on another machine and fetched over nfs or the like.

Also, neither kldxref(8) or preloading modules in loader(8) are 
implemented yet.  Its strictly kldload from the command line for the 
Peter Wemm - peter at; peter at; peter at
"All of this is for nothing if we don't go to the stars" - JMS/B5

More information about the freebsd-amd64 mailing list