Date: Sun, 16 May 2004 18:36:17 -0700 From: Peter Wemm <peter@wemm.org> To: amd64@freebsd.org Subject: Beware of dragons in module loader code! Message-ID: <200405161836.17539.peter@wemm.org>
next in thread | raw e-mail | index | archive | help
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@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200405161836.17539.peter>