libgcc, and causes problems on some platforms. Currently there is
no easy way to say "link against libgcc but not against libc", so
just comment out -nostdlibs until a better way is invented.
for orphaned sections to using PROVIDE. What this means is that
unless a rump component internally references that symbol, it will
not be included in the component shared library, and hence cannot
be referenced when the component is loaded. Add a workaround which
works both with 2.16 and 2.19: force a reference to the __start
symbol internally and hence retain it in the resulting library.
1) invoke objcopy with --preserve-dates or it will update all the
dates in the .a file to the present date.
2) add an invocation of ar-as-ranlib or the object file index ends up
with the date in it. (it might also end up with an incorrect
index.)
made to fail. Specifically, change
.ifdef(SYMBOL) -> .ifdef SYMBOL or .if defined(SYMBOL),
and corresponding for .ifndef.
Also correct one error in lib/libm/Makefile (.ifdef (${MKCOMPLEX} != "no")?!?).
lacking special instructions. We always use the spinlocked version
(could use RAS on UP NetBSD host, but it's not portable).
* Add platform-based symbol quirk tables for selectively not renaming
toolchain symbols for some platforms. Although, this should really
depend on the (toolchain,platform)-tuple and not just the platform.
This allows arm, hppa, mips and sh3 to build succesfully with an
isolated rump kernel namespace. ... now, one arch remains: vax.
you must compile vax. then, only then will you MI be.
symbols. This fixes e.g. fortify and sh3 millicode issues. This
is still not perfect, however, since e.g. the MIPS _gp_disp is not
in ^__.
XXX: we provide a few ^__ symbols in the kernel, but those can be
easily renamed. The harder problem is how to keep the kernel clean
of those afterwards.
symbol namespace. This has several implications:
* no symbols are accidentally linked against host platform libraries
* all host platform access is done via rumpuser, and hence the
portability of rump is now well defined
* functionality such as proplib can now exist within the rump virtual
kernel and the application using it
Thanks to uwe for originally suggesting the bulk renaming approach
over a pint of what I believe was very crisp, curious and untypical
stout. It had an almost acidic characteristic with fruity notes
and lacking dark and roasted flavours.
And thanks to lukem for pointing me in the right direction with make.
private non-installed build infrastructure from sys/rump.
breakdown of commit:
* install relevant headers into /usr/include/rump
* build sys/rump/librump/rumpuser and sys/rump/librump/rumpkern
from src/lib and install as librumpuser and librump, respectively
+ this retains the ability to test a librump build with just the
kernel sources at hand
* move sys/rump/fs/lib/libukfs and sys/rump/fs/lib/libp2k to src/lib
for general consumption, they are not kernel-space dwellers anyway
* build and install sys/rump/fs/lib/lib$fs as librumpfs_$fs
* add chapter 3 manual pages for rump, rumpuser, ukfs and p2k
* build and install userspace kernel file system daemons if MKPUFFS=yes
is spexified
* retire fsconsole for now, it will make a comeback with an actually
implemented version shortly
To accommodate, give the rootvnode its own vnode op vector with a
simple lookup operation. This is used for looking up the file
system's device vnode instead of doing that directly in a homesmoked
namei().
/sys/rump contains programs which run unmodified kernel code in an
emulated userspace environment. The kernel environment is provided
by librump. Currently supported are a number of file systems,
which by using puffs integrate seamlessly into the system and
provide a similar user experience to if the code was running as
part of the kernel. Potential future rumpification targets include
for example parts of the networking stack and some device drivers.
This work was supported by Google Summer of Code 2007.
pooka