NetBSD

As the project's motto ("Of course it runs NetBSD" ) suggests, NetBSD has been ported to a large number of 32- and 64-bit architectures. These range from VAX minicomputers to Pocket PC PDAs. As of 2019, NetBSD supports 59 hardware platforms (across 16 different instruction sets). The kernel and userland for these platforms are all built from a central unified source-code tree managed by CVS. Currently, unlike other kernels such as μClinux, the NetBSD kernel requires the presence of an MMU in any given target architecture.

NetBSD's portability is aided by the use of hardware abstraction layer interfaces for low-level hardware access such as bus input/output or DMA. Using this portability layer, device drivers can be split into "machine-independent" and "machine-dependent" components. This makes a single driver easily usable on several platforms by hiding hardware access details, and reduces the work to port it to a new system.[17]

This permits a particular device driver for a PCI card to work without modifications, whether it is in a PCI slot on an IA-32, Alpha, PowerPC, SPARC, or other architecture with a PCI bus. Also, a single driver for a specific device can operate via several different buses, like ISA, PCI, or PC Card.

In comparison, Linux device driver code often must be reworked for each new architecture. As a consequence, in porting efforts by NetBSD and Linux developers, NetBSD has taken much less time to port to new hardware.[18]

This platform independence aids the development of embedded systems, particularly since NetBSD 1.6, when the entire toolchain of compilers, assemblers, linkers, and other tools fully support cross-compiling.

In 2005, as a demonstration of NetBSD's portability and suitability for embedded applications, Technologic Systems, a vendor of embedded systems hardware, designed and demonstrated a NetBSD-powered kitchen toaster.[19]

Commercial ports to embedded platforms, including the AMD Geode LX800, Freescale PowerQUICC processors, Marvell Orion, AMCC 405 family of PowerPC processors, Intel XScale IOP and IXP series, were available from and supported by Wasabi Systems.

The NetBSD cross-compiling framework (also known as "build.sh"[20]) lets a developer build a complete NetBSD system for an architecture from a more powerful system of different architecture (cross-compiling), including on a different operating system (the framework supports most POSIX-compliant systems). Several embedded systems using NetBSD have required no additional software development other than toolchain and target rehost.[18]

NetBSD features pkgsrc (short for "package source"), a framework for building and managing third-party application software packages. The pkgsrc collection consists of more than 20,000 packages as of October 2019.[21] Building and installing packages such as KDE, GNOME, the Apache HTTP Server or Perl is performed through the use of a system of makefiles. This can automatically fetch the source code, unpack, patch, configure, build and install the package such that it can be removed again later. An alternative to compiling from source is to use a precompiled binary package. In either case, any prerequisites/dependencies will be installed automatically by the package system, without need for manual intervention.

pkgsrc supports not only NetBSD, but also several other BSD variants like FreeBSD and Darwin/Mac OS X, and other Unix-like operating systems such as Linux, Solaris, IRIX, and others, as well as Interix. pkgsrc was previously adopted as the official package management system for DragonFly BSD.[22]

NetBSD has supported SMP since the NetBSD 2.0 release in 2004,[23] which was initially implemented using the giant lock approach. During the development cycle of the NetBSD 5 release, major work was done to improve SMP support; most of the kernel subsystems were modified to use the fine-grained locking approach. New synchronization primitives were implemented and scheduler activations was replaced with a 1:1 threading model in February 2007.[24] A scalable M2 thread scheduler was implemented, though the old 4.4BSD scheduler still remains the default but was modified to scale with SMP. Threaded software interrupts were implemented to improve synchronization. The virtual memory system, memory allocator and trap handling were made MP safe. The file system framework, including the VFS and major file systems were modified to be MP safe. Since April 2008 the only subsystems running with a giant lock are the network protocols and most device drivers.

NetBSD provides various features in the security area.[25] The Kernel Authorization framework[26] (or Kauth) is a subsystem managing all authorization requests inside the kernel, and used as system-wide security policy. It allows external modules to plug-in the authorization process. NetBSD also incorporates exploit mitigation features, ASLR,[27] KASLR, restricted mprotect() and Segvguard from the PaX project, and GCC Stack Smashing Protection (SSP, or also known as ProPolice, enabled by default since NetBSD 6.0) compiler extensions. Verified Executables (or Veriexec) is an in-kernel file integrity subsystem in NetBSD. It allows the user to set digital fingerprints (hashes) of files, and take a number of different actions if files do not match their fingerprints. For example, one can allow Perl to run only scripts that match their fingerprints.[28] The cryptographic device driver (CGD) allows using disks or partitions (including CDs and DVDs) for encrypted storage.[29]

The Xen virtual-machine monitor has been supported in NetBSD since release 3.0. The use of Xen requires a special pre-kernel boot environment that loads a Xen-specialized kernel as the "host OS" (Dom0). Any number of "guest OSes" (DomU) virtualized computers, with or without specific Xen/DomU support, can be run in parallel with the appropriate hardware resources.

The need for a third-party boot manager, such as GRUB, was eliminated with NetBSD 5's Xen-compatible boot manager.[30] NetBSD 6 as a Dom0 has been benchmarked comparably to Linux, with better performance than Linux in some tests.[31]

As of NetBSD 9.0, accelerated virtualization is provided through the native hypervisor NVMM (NetBSD Virtual Machine Monitor).[32] It provides a virtualization API, libnvmm, that can be leveraged by emulators such as QEMU. A unique property of NVMM is that the kernel never accesses guest VM memory, only creating it.[33] HAXM provides an alternative solution for acceleration in QEMU for Intel CPUs only, similar to Linux's KVM.[34]

NetBSD 5.0 introduced the rump kernel, an architecture to run drivers in user-space by emulating kernel-space calls. This anykernel architecture allows adding support of NetBSD drivers to other kernel architectures, ranging from exokernels to monolithic kernels.[35]

NetBSD includes many enterprise features like iSCSI, a journaling filesystem, logical volume management and the ZFS filesystem.

The bio(4) interface for vendor-agnostic RAID volume management through bioctl has been available in NetBSD since 2007.[36]

The WAPBL journaling filesystem, an extension of the BSD FFS filesystem, was contributed by Wasabi Systems in 2008.[37]

The NetBSD Logical Volume Manager is based on a BSD reimplementation of a device-mapper driver and a port of the Linux Logical Volume Manager tools. It was mostly written during the Google Summer of Code 2008.[38]

The ZFS filesystem developed by Sun Microsystems was imported into the NetBSD base system in 2009. Currently, the NetBSD ZFS port is based on ZFS version 22.

The CHFS Flash memory filesystem was imported into NetBSD in November 2011. CHFS is a file system developed at the Department of Software Engineering, University of Szeged, Hungary, and is the first open source Flash-specific file system written for NetBSD.

At the source code level, NetBSD is very nearly entirely compliant with POSIX.1 (IEEE 1003.1-1990) standard and mostly compliant with POSIX.2 (IEEE 1003.2-1992).

NetBSD provides system call-level binary compatibility on the appropriate processor architectures with its previous releases, but also with several other UNIX-derived and UNIX-like operating systems, including Linux, and other 4.3BSD derivatives like SunOS 4. This allows NetBSD users to run many applications that are only distributed in binary form for other operating systems, usually with no significant loss of performance.[39]

A variety of "foreign" disk filesystem formats are also supported in NetBSD, including ZFS, FAT, NTFS, Linux ext2fs, Apple HFS and OS X UFS, RISC OS FileCore/ADFS, AmigaOS Fast File System, IRIX EFS, Version 7 Unix File System, and many more through PUFFS.

Kernel-space scripting with the Lua programming language is a relatively new feature in NetBSD; it is available as of NetBSD 7.0.[40] The Lua language (i.e., its interpreter and standard libraries) was initially ported to the NetBSD kernel during Google Summer of Code 2010 and has undergone several improvements since then. There are two main differences between user and kernel space Lua: kernel Lua does not support floating-point numbers; as such, only Lua integers are available. It also does not have full support to user space libraries that rely on the operating system (e.g., io and os).

NetBSD has featured a native hardware monitoring framework since 1999/2000, and in 2003, it served as the inspiration behind the OpenBSD's sysctl hw.sensors framework when some NetBSD drivers were being ported to OpenBSD.[41]

As of March 2019, NetBSD had close to 85 device drivers exporting data through the API of the envsys framework. Since the 2007 revision, serialisation of data between the kernel and userland is done through XML property lists with the help of NetBSD's proplib(3).