we can recurse when loading dependencies and that the kstack is limited
to something like 6 or 7KB. Having a single dependency caused an instant
double panic, and I stronly suspect some of the other strange "events"
that I have seen are possibly as a result of taking a couple of interrupts
with a large chunk of the stack already in use.
While here, fix a minor logic hiccup in a sanity check.
This is the bulk of the support for doing kld modules. Two linker_sets
were replaced by SYSINIT()'s. VFS's and exec handlers are self registered.
kld is now a superset of lkm. I have converted most of them, they will
follow as a seperate commit as samples.
This all still works as a static a.out kernel using LKM's.
Drastically quieten down the verbose load progress messages. They were
more useful for debugging than anything, but are beyond a joke when loading
a few dozen modules.
Simplify the ELF extended symbol table load format. Just take the main
symbol table and the string table that corresponds. This is what we will
be getting local symbols from. (needed for the alpha stack tracebacks).
Use the (optional) full symbol tables in lookups. This means we have to
furhter distinguish between symbols that can come from the dynamic linking
table and the complete table.
The alpha boot code now needs to be adapted as ddb/db_elf.c cannot use
the simpler format.
I have not implemented loading the extended symbol tables from the syscall
interface yet, just for preloaded modules.
I am not sure about the symbol resolution. I *think* it's possible that
a local symbol can be found in preference to a global, depending on the
search sequence and dependency tree.
- seperate unload for preloaded linker objects.
- Don't build a kernel object if running as an a.out kernel.
- extract the real kernel name rather than hardwiring "kernel" for kldstat.
(sysctl kern.bootfile getst the full name via bootinfo)
- use real addresses on the kernel "module" rather than fictitious ones.
- preloaded module support
- search module path for file modules.
- symbols are checked to see if they are in the right containing file
before using their indexes into string tables. This is to help ddb
since it only supplies a pointer to an opaque symbol and there is no
telling which file/object/module/whatever it came from.
