$NetBSD: README.compileopts,v 1.6 2014/07/11 20:26:31 justin Exp $ This file describes compile-time options for rump kernels. Additionally, NetBSD build options will have an effect. See src/share/mk/bsd.README for a desciption of NetBSD build options. Note: after changing an option, do a clean build. Global options: RUMP_DIAGNOSTIC values: yes|no defval: yes effect: Iff "yes", build with -DDIAGNOSTIC. RUMP_DEBUG values: defined / not defined effect: Iff defined, build with -DDEBUG. RUMP_LOCKDEBUG values: defined / not defined effect: Iff defined, build with -DLOCKDEBUG. RUMP_KTRACE values: yes|no defval: yes effect: Iff "yes", build with -DKTRACE. RUMP_LOCKS_UP values: yes|no defval: no effect: If "yes", build rump kernel with uniprocess-optimized locking. An implication of this is that RUMP_NCPU==1 is required at runtime. If "no", build with multiprocessor-capable locking. RUMP_UNREAL_ALLOCATORS values: yes|no defval: no effect: If "yes", build version of kmem_alloc, pool and pool_cache that directly relegate allocation to a hypercall. If "no", build the regular NetBSD memory allocators which use page-sized memory allocation hypercalls. RUMP_VIRTIF values: yes|no defval: yes effect: Iff "yes", build the virt(4) network interface. Turning this off may be necessary on systems that lack the necessary headers, e.g. musl libc based Linux. RUMP_CURLWP values: hypercall/__thread/register or defval: effect: Control how curlwp is obtained in a rump kernel. This is a very frequently accessed thread-local variable, and optimizing access has a significant performance impact. Note that all options are not available on hosts/machine architectures. - use default implementation (currently "hypercall") hypercall - use a hypercall to fetch the value __thread - use the __thread feature to fetch value via TLS register - use a dedicated register (implies -ffixed) ================================================================================ Rumpuser options: RUMPUSER_THREADS values: pthread/none/fiber or defval: effect: Define the way threading is implemented in the rumpuser hypercall implmentation. - use default implementation (currently "pthread") pthread - use pthreads to implement threading none - do not support kernel threads at all fiber - user a fiber interface, cooperatively scheduled contexts ================================================================================ Per-component options: RUMP_SYM_NORENAME values: regexp matching symbol names defval: effect: Causes matching symbols from the component to not be renamed into the rump kernel symbol namespace (rumpns_). This option can only be used in embedded environments where there is full control over the platform's namespace. Conversely, this option cannot be used in kernel components which are not meant to be tied to a specific platform. Note: the value is processed by make and must be appropriately escaped. example: RUMP_SYM_NORENAME=HYPERVISOR_|block$$ will not rename "^HYPERVISOR_" or "^block$" ================================================================================ The rest of the options described in this file are not intended to be set by users, but by the package building rump kernels. RUMP_KERNEL_IS_LIBC values: defined / not defined effect: Iff defined, export normal system call symbols from libc. For example, without this option rump_sys_open() is exported. With this option, both open() and rump_sys_open() are exported. This option is meant for building systems where a rump kernel is the only operating system like component. RUMP_LDSCRIPT values: no/GNU/sun/ctor defval: GNU effect: Select the linker script to be used for linking rump kernel shared library components. no - do not use a linker script GNU - use a linker script for GNU ld 2.18 and later sun - use a linker script for the Solaris linker ctor - do not use a linker script, make the code generate __attribute__((constructor))