We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Rump Kernels, Just Components

Formale Metadaten

Titel
Rump Kernels, Just Components
Serientitel
Anzahl der Teile
199
Autor
Lizenz
CC-Namensnennung 2.0 Belgien:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr2014
SpracheEnglisch

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
The talk will concentrate more on anecdotes from the "drivers first" development approach. Technical details for how rump kernels work will be provided as links. Rump kernels are NetBSD kernel drivers running on top of a set of high-level hypercalls. The term "drivers" is used in the broad sense, and includes for example file system, TCP/IP and system call drivers. The hypercall interface makes virtually no assumptions about the host, apart from it being able to execute code and access I/O functions required by the drivers (e.g. NIC-like devices for the networking stack). The original motivation for rump kernels was being able to debug NetBSD kernel drivers in a nice, non-monolithic kernel environment (i.e. userspace processes). This motivation dictated that drivers running in the non-monolithic environment had to be unmodified with respect to the NetBSD kernel version under the hammer. The implication was that instead of modifying drivers to work in userspace, NetBSD was modified to allow the drivers to run anywhere. The result of work begun in 2007 is that NetBSD kernel drivers from any snapshot or release of NetBSD now run more or less anywhere: in userspace on most operating systems, in a web browser, on top of the Xen hypervisor, or in the Linux kernel. The only component required for running NetBSD kernel drivers in a given environment is the rump kernel hypercall implementation. This implementation generally speaking 1000 lines of code (figure includes comments and whitespace and rudimentary I/O access routines)