modules in bootstrap, just add them. Load them later the same way
as the kernel does: module_init_class().
Change the signature of rump_module_init() to take a vector instead
of just one module. All modules in a DSO should be init'd at the
same time because they might depend on each other, and code outside
the rump kernel cannot know which way. (binary kernel modules are
still loaded with rump_sys_modctl() the usual way).
module which is linked into the kernel and cannot be unloaded.
The main purpose is to get the proper constructors run and create
any /dev nodes necessary for said component. Once more of the
kernel (e.g. networking stack and device drivers) are converted to
MODULE and devfs pops up from somewhere, rump components can be
retired.
the source files from src/sys/rump/librump/rumpuser to src/lib/librumpuser
(from where it is already built). Even so, keep rumpuser.h in
sys/rump/include for kernel source tree self-containment.
on the amount of physical memory and limited by NMBCLUSTERS if present.
Architectures without direct mapping also limit it based on the kmem_map
size, which is used as backing store. On i386 and ARM, the maximum KVA
used for mbuf clusters is limited to 64MB by default.
The old default limits and limits based on GATEWAY have been removed.
key_registered_sb_max is hard-wired to a value derived from 2048
clusters.
#if NBPFILTER is no longer required in the client. This change
doesn't yet add support for loading bpf as a module, since drivers
can register before bpf is attached. However, callers of bpf can
now be modularized.
Dynamically loadable bpf could probably be done fairly easily with
coordination from the stub driver and the real driver by registering
attachments in the stub before the real driver is loaded and doing
a handoff. ... and I'm not going to ponder the depths of unload
here.
Tested with i386/MONOLITHIC, modified MONOLITHIC without bpf and rump.
an absolute time instead of a delta. Fix bug which caused timed
tsleeps to always wake up immediately (unless the system clock was
around "0", which was not very probable ;).
pooka