Beware of dragons in module loader code!
Peter Wemm
peter at wemm.org
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
sizeof().
- 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
moment.
--
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
More information about the freebsd-amd64
mailing list