care about the arch as long as all the devices we care about are
present). The file should be autogenerated, but that requires some
more changes to config(1).
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.
currently there. Still needs a little massage to get the kernel
interfaces right and avoid copypaste especially from main().
Also, move it a bit more into the direction of a real file system
(finally!) by giving it a vfsops. Most ops are still unimplemented,
though.
all-sink and make sure each separate thread in rump has its own
lwp. Happy-go-lucky callers will get scheduled a temporary lwp
on entry, while true lwp connoisseurs may request a stable lwp
for their purposes. Some more love may be required later down the
road, but for now different threads will stepping on each others
toes.
for kernel code which has been written to avoid MP contention by
using cpu-local storage (most prominently, select and pool_cache).
Instead of always assuming rump_cpu, the scheduler must now be run
(and unrun) on all entry points into rump. Likewise, rumpuser
unruns and re-runs the scheduler around each potentially blocking
operation. As an optimization, I modified some locking primitives
to try to get the lock without blocking before releasing the cpu.
Also, ltsleep was modified to assume that it is never called without
the biglock held and made to use the biglock as the sleep interlock.
Otherwise there is just too much drama with deadlocks. If some
kernel code wants to call ltsleep without the biglock, then, *snif*,
it's no longer supported and rump and should be modified to support
newstyle locks anyway.
kernels running in other processes on the same machine or on an
entirely different host. I wrote this a while ago and am now
committing it mainly to avoid losing it. It works, but could do
with a little tuning here and there.
What this will hopefully eventually buy us is the ability to use
standard userland tools to configure rump kernels, e.g. ifconfig(8)
and route(8) could be used to configure the networking stack provided
by a rump kernel. Also some distributed OS implications may apply.
fun fact: a system call which just does copyin/copyout takes >1000x
longer when made over the LAN as compared to when made on the same
machine.
