Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

rump_lwproc(3) [netbsd man page]

RUMP_LWPROC(3)						   BSD Library Functions Manual 					    RUMP_LWPROC(3)

NAME
rump_lwproc -- rump process/lwp management LIBRARY
rump kernel (librump, -lrump) SYNOPSIS
#include <rump/rump.h> int rump_pub_lwproc_rfork(int flags); int rump_pub_lwproc_newlwp(pid_t pid); void rump_pub_lwproc_switch(struct lwp *l); void rump_pub_lwproc_releaselwp(); struct lwp * rump_pub_lwproc_curlwp(); DESCRIPTION
In a normal operating system model a process is a resource container and a thread (lwp) is the execution context. Every lwp is associated with exactly one process, and a process is associated with one or more lwps. The current lwp (curlwp) indicates the current process and determines which resources, such as UID/GID, current working directory, and file descriptor table, are currently used. These basic princi- ples apply to rump kernels as well, but since rump uses the host's thread and process context directly, the rules for how thread context is determined are different. In the rump model, each host thread (pthread) is either bound to a rump kernel lwp or accesses the rump kernel with an implicit thread con- text associated with pid 1. An implicit thread context is created every time the rump kernel is entered and disbanded upon exit. While con- venient for occasional calls, creating an implicit thread uses a shared resource which can become highly contended in a multithreaded situa- tion. It is therefore recommended that dedicated threads are created. The association between host threads and the rump kernel curlwp is left to the caller. It is possible to create a dedicated host thread for every rump kernel lwp or multiplex them on top of a single host thread. After rump lwps have been created, switching curlwp is very cheap -- faster than a thread context switch on the host. In case multiple lwps/processes are created, it is the caller's responsibility to keep track of them and release them when they are no longer necessary. Like other rump kernel resources, procs/lwps will be released when the process hosting the rump kernel exits. rump_pub_lwproc_rfork() Create a process, one lwp inside it and set curlwp to the new lwp. The flags parameter controls how file descriptors are inherited from the parent. By default (flags=0) file descriptors are shared. Other options are: RUMP_RFFDG Copy file descriptors from parent. This is what fork(2) does. RUMP_RFCFDG File descriptors neither copied nor shared, i.e. new process does not have access to the parent's file descriptors. This routine returns 0 for success or an errno indicating the reason for failure. The new process id can be retrieved in the normal fashion by calling rump_sys_getpid(). rump_pub_lwproc_newlwp(pid) Create a new lwp attached to the process specified by pid. Sets curlwp to the new lwp. This routine returns 0 for success or an errno indicating the reason for failure. rump_pub_lwproc_switch(l) Sets curlwp to l. In case the new thread is associated with a different process than the current one, the process context is also switched. The special value NULL sets curlwp to implicit context. Switching to an already running lwp, i.e. attempting to use the same curlwp in two host threads simultaneously causes a fatal error. rump_pub_lwproc_releaselwp() Release curlwp and set curlwp to context. In case curlwp was the last thread inside the current process, the process container is also released. Calling this routine without a dedicated curlwp is a fatal error. rump_pub_lwproc_curlwp() Returns curlwp or NULL if the current context is an implicit context. SEE ALSO
getpid(2), rump(3) HISTORY
rump_lwproc first appeared in NetBSD 6.0. BSD
January 2, 2011 BSD

Check Out this Related Man Page

RUMP_SP(7)					       BSD Miscellaneous Information Manual						RUMP_SP(7)

NAME
rump_sp -- rump remote system call support DESCRIPTION
The rump_sp facility allows clients to attach to a rump kernel server over a socket and perform system calls. While making a local rump sys- tem call is faster than calling the host kernel, a remote system call over a socket is slower. This facility is therefore meant mostly for operations which are not performance critical, such as configuration of a rump kernel server. Clients The NetBSD base system comes with multiple preinstalled clients which can be used to configure a rump kernel and request diagnostic informa- tion. These clients run as hybrids partially in the host system and partially against the rump kernel. For example, network-related clients will typically avoid making any file system related system calls against the rump kernel, since it is not guaranteed that a rump network server has file system support. Another example is DNS: since a rump server very rarely has a DNS service configured, host networking is used to do DNS lookups. Some examples of clients include rump.ifconfig which configures interfaces, rump.sysctl which is used to access the sysctl(7) namespace and rump.traceroute which is used to display a network trace starting from the rump kernel. Also, almost any unmodified dynamically linked application (for example telnet(1) or ls(1)) can be used as a rump kernel client with the help of system call hijacking. See rumphijack(3) for more information. Connecting to the server A remote rump server is specified using an URL. Currently two types of URLs are supported: TCP and local domain sockets. The TCP URL is of the format tcp://ip.address:port/ and the local domain URL is unix://path. The latter can accept relative or absolute paths. Note that absolute paths require three leading slashes. To preserve the standard usage of the rump clients' counterparts the environment variable RUMP_SERVER is used to specify the server URL. To keep track of which rump kernel the current shell is using, modifying the shell prompt is recommended -- this is analoguous to the visual clue you have when you login from one machine to another. Client credentials and access control The current scheme gives all connecting clients root credentials. It is recommended to take precautions which prevent unauthorized access. For a unix domain socket it is enough to prevent access to the socket using file system permissions. For TCP/IP sockets the only available means is to prevent network access to the socket with the use of firewalls. More fine-grained access control based on cryptographic creden- tials may be implemented at a future date. EXAMPLES
Get a list of file systems supported by a rump kernel server (in case that particular server does not support file systems, an error will be returned): $ env RUMP_SERVER=unix://sock rump.sysctl vfs.generic.fstypes SEE ALSO
rump_server(1), rump(3), rumpclient(3), rumphijack(3) HISTORY
rump_sp first appeared in NetBSD 6.0. BSD
February 7, 2011 BSD
Man Page