NetBSD

Como sugiere el lema del proyecto ( "Por supuesto que ejecuta NetBSD" ), NetBSD se ha adaptado a numerosas arquitecturas de 32 y 64 bits . Estas abarcan desde minicomputadoras VAX hasta PDAs Pocket PC . NetBSD también se ha adaptado a varias consolas de videojuegos como la Sega Dreamcast ^{[ 20 ]} y la Nintendo Wii . ^{[ 21 ]} A partir de 2019, NetBSD admite 59 plataformas de hardware (a través de 16 conjuntos de instrucciones diferentes ). El kernel y el espacio de usuario para estas plataformas se construyen a partir de un árbol de código fuente centralizado y unificado administrado por CVS . A diferencia de otros kernels como μClinux , el kernel de NetBSD requiere la presencia de una MMU en cualquier arquitectura de destino dada.

La portabilidad de NetBSD se ve favorecida por el uso de interfaces de capa de abstracción de hardware para el acceso de bajo nivel al hardware, como la entrada/salida del bus o DMA . Mediante esta capa de portabilidad, los controladores de dispositivos se pueden dividir en componentes "independientes de la máquina" (MI) y "dependientes de la máquina" (MD). Esto permite que un único controlador sea fácilmente utilizable en varias plataformas al ocultar los detalles de acceso al hardware y reduce el trabajo necesario para portarlo a un nuevo sistema. ^{[ 22 ]}

Esto permite que un controlador de dispositivo específico para una tarjeta PCI funcione sin modificaciones, ya sea en una ranura PCI de una arquitectura IA-32 , Alpha , PowerPC , SPARC u otra con bus PCI. Además, un único controlador para un dispositivo específico puede funcionar a través de varios buses diferentes, como ISA , PCI o PC Card .

Esta independencia de plataforma facilita el desarrollo de sistemas embebidos , especialmente desde NetBSD 1.6, cuando toda la cadena de herramientas de compiladores , ensambladores , enlazadores y otras herramientas admite plenamente la compilación cruzada .

En 2005, como demostración de la portabilidad y la idoneidad de NetBSD para aplicaciones embebidas, Technologic Systems, un proveedor de hardware para sistemas embebidos, diseñó y demostró una tostadora de cocina con NetBSD . ^{[ 23 ]}

Wasabi Systems ofrecía y brindaba soporte para versiones comerciales de plataformas integradas, incluyendo plataformas como AMD Geode LX800, procesadores Freescale PowerQUICC , Marvell Orion, la familia de procesadores PowerPC AMCC 405 y las series Intel XScale IOP e IXP.

El marco de compilación cruzada de NetBSD (también conocido como "build.sh" ^{[ 24 ]} ) permite a un desarrollador construir un sistema NetBSD completo para una arquitectura a partir de un sistema más potente de arquitectura diferente ( compilación cruzada ), incluso en un sistema operativo diferente (el marco admite la mayoría de los sistemas compatibles con POSIX ). Varios sistemas embebidos que utilizan NetBSD no han requerido desarrollo de software adicional más allá de la cadena de herramientas y la reubicación del destino. ^{[ 25 ]}

A partir de 2017, NetBSD había logrado compilaciones totalmente reproducibles en amd64 y SPARC64 . ^{[ 26 ]} La -Pbandera build.sh maneja compilaciones reproducibles automáticamente.

NetBSD incluye pkgsrc (abreviatura de "package source"), un marco de trabajo para crear y gestionar paquetes de software de aplicaciones de terceros . La colección de pkgsrc consta de más de 29 000 paquetes a septiembre de 2025.[ ^{27 ]} La compilación e instalación de paquetes como Lumina , KDE , GNOME , el servidor HTTP Apache o Perl se realiza mediante un sistema de ^makefiles . Este sistema puede descargar automáticamente el código fuente, descomprimir, parchear, configurar , compilar e instalar el paquete para que pueda eliminarse posteriormente. Una alternativa a la compilación desde el código fuente es utilizar un paquete binario precompilado. En ambos casos, el sistema de paquetes instalará automáticamente los prerrequisitos o dependencias, sin necesidad de intervención manual.

pkgsrc es un sistema de empaquetado multiplataforma , ya que no solo admite NetBSD, sino que también puede utilizarse en varias otras plataformas tipo Unix , entre las que macOS , Solaris y Linux se consideran objetivos principales. ^{[ 28 ]} Otros sistemas BSD , HP-UX , Minix , SCO UNIX ( Unixware y OpenServer ) y QNX tienen varios usuarios activos de pkgsrc, pero no reciben mantenimiento activo.

pkgsrc es el sistema de gestión de paquetes predeterminado en SmartOS ^{[ 29 ]} y Minix3 . ^{[ 30 ]} También fue adoptado previamente como el sistema oficial de gestión de paquetes para DragonFly BSD , ^{[ 31 ]} y se puso a disposición como un marco de empaquetado alternativo en MirBSD ^{[ 32 ]} y QNX. ^{[ 33 ]}

NetBSD ha sido compatible con SMP desde el lanzamiento de NetBSD 2.0 en 2004, ^{[ 34 ]} que inicialmente se implementó utilizando el enfoque de bloqueo gigante .

Durante el ciclo de desarrollo de la versión NetBSD 5, se realizó un trabajo importante para mejorar la compatibilidad con SMP; la mayoría de los subsistemas del kernel se modificaron para usar el enfoque de bloqueo de grano fino . Se implementaron nuevas primitivas de sincronización y las activaciones del planificador se reemplazaron con un modelo de subprocesos 1:1 en febrero de 2007. ^{[ 35 ] [ 36 ]} También se implementó un planificador de subprocesos M2 escalable, ^{[ 37 ]} que proporciona colas separadas de tiempo real (RT) y de tiempo compartido (TS), y mejora el rendimiento en sistemas MP. Se implementaron interrupciones de software de subprocesos para mejorar la sincronización. El sistema de memoria virtual , el asignador de memoria y el manejo de trampas se hicieron seguros para MP. El marco del sistema de archivos, incluidos VFS y los principales sistemas de archivos, se modificaron para ser seguros para MP. A partir de NetBSD 10.0, los únicos subsistemas que se ejecutan con un bloqueo gigante son los controladores de dispositivos SATA , los manejadores de interrupciones , el marco autoconf(9) y la mayor parte de la pila de red , a menos que se habilite la opción del kernel. ^{[ 38 ]}NET_MPSAFE

En realidad, a partir de la versión 8.0, varias partes de la pila de red ya se han hecho seguras para MP, ^{[ 39 ]} pero NET_MPSAFE se mantiene deshabilitado por defecto, porque los componentes no seguros para MP que tampoco están protegidos por el bloqueo gigante podrían, de lo contrario, provocar el fallo del kernel cuando se cargan en la memoria. ^{[ 40 ]}

El planificador 4.4BSD sigue siendo el predeterminado, pero se modificó para escalar con SMP, fusionando características de SCHED_M2. ^{[ 41 ]} En 2017, el planificador se cambió para distribuir mejor la carga de procesos de larga duración en múltiples CPU, y se introdujeron parámetros kern.schedsysctl (3) ajustables. ^{[ 42 ]} El lanzamiento de NetBSD 10.0 trajo mejoras de rendimiento significativas, especialmente en sistemas multiprocesador y multinúcleo; ^{[ 43 ]} el planificador obtuvo mayor conocimiento de NUMA e hyperthreading , y se volvió capaz de distribuir la carga uniformemente entre diferentes CPU físicas, así como de escalar mejor en una mezcla de núcleos lentos y rápidos (por ejemplo, ARM big.LITTLE ). ^{[ 44 ]}

NetBSD admite una serie de características diseñadas para mejorar la seguridad del sistema . ^{[ 45 ]} Algunas se enumeran a continuación.

El marco de autorización del kernel ^{[ 46 ]} (o kauth) es un subsistema que gestiona todas las solicitudes de autorización dentro del kernel y se utiliza como política de seguridad para todo el sistema. kauth(9) actúa como un guardián entre las rutinas del propio kernel, comprobando si una llamada determinada o una operación específica está permitida dentro del contexto y devuelve EPERM si no lo está. ^{[ 47 ]} La ​​mayoría de las llamadas al sistema emiten una solicitud de autorización en su controlador correspondiente a través de kauth_authorize_action(). kauth también permite que módulos externos se integren en el proceso de autorización.

Verified Executables (o Veriexec) es un subsistema de integridad de archivos integrado en el núcleo de NetBSD. Permite al usuario establecer huellas digitales (hashes) de los archivos y realizar diversas acciones si estos no coinciden con dichas huellas. Por ejemplo, se puede configurar Perl para que ejecute únicamente los scripts que coincidan con sus huellas digitales. ^{[ 48 ]}

A partir de la versión 2.0, NetBSD admite asignaciones no ejecutables en plataformas donde el hardware lo permite. ^{[ 49 ]} Las asignaciones de pila de procesos y de montón no son ejecutables por defecto. Esto dificulta la explotación de posibles desbordamientos de búfer . NetBSD admite PROT_EXECpermisos a través de mmap()para todas las plataformas donde el hardware diferencia el acceso de ejecución del acceso de datos, aunque no necesariamente con granularidad de una sola página. ^{[ 50 ]}

NetBSD implementa varias características de mitigación de exploits , como ASLR (tanto en el espacio de usuario como en el kernel ^{[ 51 ] [ 52 ]} ), restricted mprotect()( W^X ) y Segvguard del proyecto PaX , y extensiones del compilador GCC Stack Smashing Protection (SSP, o también conocido como ProPolice, habilitado por defecto desde NetBSD 6.0).

El controlador de dispositivo criptográfico (CGD) proporciona cifrado de disco transparente al actuar como un dispositivo lógico que se superpone a otro dispositivo de bloques, como un disco físico o partición (incluidos CD y DVD) o un pseudodispositivo vnd(4) . ^{[ 53 ]} Admite el cifrado Adiantum , además de AES en los modos CBC/XTS. ^{[ 54 ]}

NPF , introducido con NetBSD 6.0, ^{[ 55 ]} es un filtro de paquetes de capa 3 que admite inspección de paquetes con estado , IPv6 , NAT , conjuntos de IP y extensiones. ^{[ 56 ]} Utiliza BPF como su motor principal y admite bpfjit . NPF fue diseñado con un enfoque en alto rendimiento, escalabilidad, multihilo y modularidad.

También son relevantes para la seguridad los niveles seguros de BSD , ^{[ 57 ]} blocklistd(8), un demonio capaz de bloquear puertos bajo demanda para evitar abusos de DoS , ^{[ 58 ]} y la interfaz wg(4), que proporciona una implementación propia del protocolo WireGuard . ^{[ 59 ]}

El código de NetBSD se escanea periódicamente en busca de errores , y los avisos de seguridad —que contienen un enlace a la solución— se publican en las listas de correo oficiales. ^{[ 60 ]}

NetBSD utiliza el sistema de memoria virtual UVM ^{[ 61 ]} , desarrollado por Charles D. Cranor en la Universidad de Washington en 1998, e incorporado al árbol de código fuente de NetBSD por Matthew Green, quien manejó los problemas de integración y escribió el subsistema de intercambio . ^{[ 62 ]}

El sistema original 4.4BSD basado en Mach ^{[ 63 ]} fue reemplazado por UVM en NetBSD 1.4. ^{[ 64 ]} UVM está diseñado para reducir la complejidad del sistema de máquina virtual 4.4BSD y ofrecer un rendimiento mejorado para aquellas aplicaciones que hacen un uso intensivo de las características de la máquina virtual, como los archivos mapeados en memoria y la copia en escritura de memoria. ^{[ 65 ]}

Si bien conserva las mismas estructuras de capas y mapeo MD/MI de la máquina virtual BSD, ^{[ 66 ]} UVM introduce algunos cambios notables:

• Los objetos de memoria se asignan y gestionan en cooperación con su fuente de datos subyacente (normalmente vnodes ), lo que reduce la sobrecarga de la gestión de la cadena vm_object . La vm_pageestructura describe cómo se puede acceder al almacenamiento subyacente. En esencia, se trata de un puntero a una lista de funciones que actúan como puente entre UVM y el almacenamiento subyacente externo (como un disco) que proporciona a UVM sus datos. El objeto de memoria de UVM apunta directamente a las operaciones de paginación , lo que hace que la asignación de estructuras de datos relacionadas con la paginación sea más eficiente.
• Las páginas anónimas se agrupan en clústeres de varias páginas para su paginación . Se asigna una ubicación a cada página en la memoria de intercambio, de modo que el clúster ocupe un bloque contiguo de dicha memoria y pueda paginarse en una única operación de E/S de gran tamaño . Esto mejora el tiempo de respuesta de paginación para las operaciones de E/S y permite que UVM se recupere más rápidamente de la escasez de páginas.
• El uso compartido de memoria se admite mediante tres mecanismos de movimiento de datos: préstamo de página , transferencia de página y paso de entrada de mapa . ^{[ 67 ]} Un proceso puede permitir de forma segura que una copia compartida de su memoria con copia en escritura sea utilizada por otros procesos, el sistema de E/S o el sistema IPC . La caché de búfer unificada (ubc(9) ^{[ 68 ]} ), escrita por Chuck Silvers, permite usar páginas UVM para almacenar en caché los datos de vnode en lugar de la caché de búfer UNIX tradicional. ^{[ 69 ]} Esto evita costosas copias de datos y hace que haya más memoria disponible para almacenar en caché los datos de archivos regulares.

En 2003, UVM se modificó para usar una administración de memoria de arriba hacia abajo, fusionando así el espacio reservado para el crecimiento del montón y el área de espacio reservada para asignaciones mmap (2). ^{[ 70 ]} Esto permite que el montón crezca más, o que un proceso asigne más objetos o de mayor tamaño mediante mmap.

Se agregó soporte para la conexión en caliente de RAM en 2016. ^{[ 71 ]} La API uvm_hotplug(9) reemplaza la vm_physmemmatriz estática expuesta anteriormente con un respaldo de árbol rojo-negro para realizar un seguimiento de los segmentos de memoria, lo que permite que la lista de páginas físicas se expanda o contraiga dinámicamente.

Durante el ciclo de lanzamiento de NetBSD 10.0, se realizó un trabajo importante para optimizar el sistema de memoria virtual. ^{[ 72 ]} El asignador de páginas se reescribió para ser más eficiente y consciente de la topología de la CPU, agregando soporte NUMA preliminar . El algoritmo utilizado en la caché de búsqueda de páginas de memoria se cambió a un árbol radix más rápido . El seguimiento y la indexación de páginas limpias/ modificadas se mejoraron, acelerando fsync(2) en archivos grandes en órdenes de magnitud. La contención de bloqueo se redujo haciendo que el mantenimiento del estado de reemplazo de páginas fuera más concurrente.

El monitor de máquinas virtuales Xen es compatible con NetBSD desde la versión 3.0. El uso de Xen requiere un entorno de arranque previo al kernel que carga un kernel especializado para Xen como sistema operativo anfitrión (Dom0). Se pueden ejecutar en paralelo varios sistemas operativos invitados (DomU), con o sin soporte específico para Xen/DomU, utilizando los recursos de hardware adecuados.

La necesidad de un gestor de arranque de terceros , como GRUB , se eliminó con el gestor de arranque compatible con Xen de NetBSD 5. ^{[ 73 ]} NetBSD 6 como Dom0 ha sido comparado con Linux, con un mejor rendimiento que Linux en algunas pruebas. ^{[ 74 ]}

A partir de NetBSD 9.0, la virtualización acelerada se proporciona a través del hipervisor nativo de tipo 2 NVMM (NetBSD Virtual Machine Monitor). ^{[ 75 ]} Proporciona una API de virtualización, libnvmmque puede ser aprovechada por emuladores como QEMU . ^{[ 76 ] [ 77 ]} El controlador NVMM del kernel viene como un módulo del kernel de carga dinámica , compuesto por un frontend genérico independiente de la máquina, al que se pueden conectar backends dependientes de la máquina para implementar la virtualización del núcleo (actualmente solo se admiten x86 AMD SVM e Intel VMX). ^{[ 78 ]} Una propiedad única de NVMM es que el kernel nunca accede a la memoria de la VM invitada, solo la crea. ^{[ 79 ]} El Administrador de ejecución acelerada por hardware (HAXM) de Intel proporciona una solución alternativa para la aceleración en QEMU solo para CPU Intel, similar al KVM de Linux . ^{[ 80 ]}

NetBSD 5.0 ​​introdujo el núcleo rump, ^{[ 81 ]} una arquitectura para ejecutar controladores en el espacio de usuario mediante la emulación de llamadas en el espacio del núcleo. Un núcleo rump puede considerarse un entorno de ejecución de controladores virtualizado, ligero y portátil, caracterizado por un bajo consumo de memoria y una superficie de ataque minimizada . ^{[ 82 ]}

El núcleo de un kernel de rump contiene un conjunto de rutinas fundamentales que le permiten acceder a los recursos de la plataforma anfitriona, como la memoria virtual , el planificador de subprocesos y las funciones de E/S . Esto se denomina interfaz de hiperllamada rampuser(3). ^{[ 83 ]} Los diversos subsistemas del kernel (por ejemplo, la pila TCP/IP , los sistemas de archivos, los controladores de dispositivos de hardware ), denominados globalmente controladores , se superponen a la interfaz de hiperllamada, al estar vinculados a una versión simplificada del kernel de NetBSD que puede ejecutarse en modo usuario. La mayoría de los controladores son opcionales y pueden incluirse o no según la aplicación y el alcance de destino.

Este diseño "anykernel" permite agregar soporte para controladores NetBSD a otras arquitecturas de kernel, ^{[ 84 ]} que van desde exokernels hasta kernels monolíticos . ^{[ 85 ]} Otras posibles aplicaciones de los kernels rump incluyen el despliegue de un unikernel específico para tareas para proporcionar una API POSIX para aplicaciones que dependen de él, ejecutar una base de datos autocontenida con huellas mínimas, ^{[ 86 ]} una instancia de WireGuard en el espacio de usuario , ^{[ 87 ]} editar el contenido de un sistema de archivos como usuario sin privilegios y segregar un navegador web a su propia pila TCP/IP. ^{[ 88 ]}

Los núcleos Rump también son utilizados internamente por el proyecto NetBSD para ejecutar pruebas en diferentes subsistemas del núcleo, así como para fines de depuración . ^{[ 89 ]}

NetBSD incluye muchas características empresariales como iSCSI , un sistema de archivos con registro de transacciones , gestión de volúmenes lógicos y el sistema de archivos ZFS .

La interfaz bio(4) para la administración de volúmenes RAID independiente del proveedor a través de bioctl ha estado disponible en NetBSD desde 2007. ^{[ 90 ]} El soporte para RAID por software se proporciona como una adaptación de CMU RAIDframe, disponible desde NetBSD 1.4. ^{[ 91 ]} El controlador ccd(4) proporciona la capacidad de combinar uno o más discos/particiones en un disco virtual, actuando como otro subsistema RAID 0 en el kernel. ^{[ 92 ]}

UFS2, una extensión de BSD FFS que agrega punteros de bloque de 64 bits , bloques de tamaño variable (similares a las extensiones ) y campos de bandera extendidos, fue portado desde FreeBSD en 2003 ^{[ 93 ]} y se puso a disposición desde NetBSD 2.0. ^{[ 94 ]} El controlador de instantáneas fss(4) ^{[ 95 ]} se introdujo el mismo año, ^{[ 96 ]} permitiendo crear una vista atómica de solo lectura de un sistema de archivos FFS en un punto dado en el tiempo; una instantánea FFS funciona como un dispositivo especial , que se puede montar y usar junto con utilidades como dump(8) para crear y exportar copias de seguridad del sistema . ^{[ 97 ]}

WAPBL , una extensión del sistema de archivos FFS que proporciona registro de datos, fue aportada por Wasabi Systems en 2008. ^{[ 98 ]} El registro permite una rápida consistencia del sistema de archivos después de un apagado incorrecto y mejora el rendimiento de escritura al reducir las escrituras de metadatos síncronas , especialmente al crear una gran cantidad de inodos. ^{[ 99 ]} El soporte para actualizaciones suaves en NetBSD FFS (v1/2) finalmente se eliminó en favor de WAPBL. ^{[ 100 ]}

A partir de la versión 10.0, FFSv2 también admite atributos de archivo extendidos y ACL ^{[ 101 ]} así como TRIM de datos . ^{[ 102 ]}

El sistema de archivos ZFS desarrollado por Sun Microsystems se importó al sistema base NetBSD en 2009. ^{[ 103 ]} En 2018, el código fuente de ZFS se actualizó y se basó en la implementación de FreeBSD . ^{[ 104 ]} ZFS finalmente se marcó como seguro para uso diario en NetBSD 9.0. ^{[ 105 ]} A partir de la versión 10.0, la pila ZFS de NetBSD es comparable a la de FreeBSD 12 (o inferior), con la versión del sistema de archivos ZFS "5.3", versión de zpool "5000" (algunas banderas de características no son compatibles). ^{[ 106 ] [ 107 ]} El cifrado nativo de ZFS está notablemente ausente, aunque se puede crear un zpool dentro de un disco cifrado cgd(4). ^{[ 108 ]} El soporte inicial para la raíz ZFS está disponible, pero no está integrado ni en el instalador ni en el cargador de arranque. ^{[ 109 ]}

El Administrador de volúmenes lógicos de NetBSD se basa en una reimplementación BSD de un controlador de mapeo de dispositivos y una adaptación de las herramientas del Administrador de volúmenes lógicos de Linux . Fue escrito principalmente durante el Google Summer of Code 2008. ^{[ 110 ]}

El sistema de archivos de memoria flash CHFS se importó a NetBSD en noviembre de 2011. CHFS es un sistema de archivos desarrollado en el Departamento de Ingeniería de Software de la Universidad de Szeged , Hungría , y es el primer sistema de archivos de código abierto específico para memoria flash escrito para NetBSD.

El marco PUFFS , introducido en NetBSD 5.0, ^{[ 111 ]} es un subsistema del kernel diseñado para ejecutar sistemas de archivos en el espacio de usuario y proporciona compatibilidad con la API de nivel de kernel FUSE junto con el demonio de espacio de usuario perfused(8).

Una implementación de tmpfs para NetBSD que utiliza estructuras de datos en memoria convencionales fue desarrollada por primera vez por Julio M. Merino Vidal en 2005 como un proyecto de GSoC , ^{[ 112 ]} y se fusionó ese mismo año en el árbol de código fuente de NetBSD. ^{[ 113 ]}

A nivel de código fuente, NetBSD cumple casi por completo con el estándar POSIX .1 (IEEE 1003.1-1990) y en su mayor parte con el estándar POSIX.2 (IEEE 1003.2-1992).

NetBSD proporciona compatibilidad binaria a nivel de llamadas al sistema en las arquitecturas de procesador apropiadas con sus versiones anteriores, pero también con varios otros sistemas operativos derivados de UNIX y similares a UNIX, incluidos Linux y otros derivados de 4.3BSD como SunOS 4. Esto permite a los usuarios de NetBSD ejecutar muchas aplicaciones que solo se distribuyen en formato binario para otros sistemas operativos, generalmente sin una pérdida significativa de rendimiento. ^{[ 114 ]} El soporte inicial para una capa de compatibilidad binaria de Haiku se publicó en la lista de correo netbsd-user. ^{[ 115 ]}

NetBSD también admite una variedad de formatos de sistema de archivos de disco "extranjeros", incluidos ZFS , FAT , NTFS , Linux ext2fs , Apple HFS y Mac OS X UFS , RISC OS FileCore/ADFS, AmigaOS Fast File System , IRIX EFS , Version 7 Unix File System y muchos más a través de PUFFS .

WINE se puede instalar en NetBSD a través de pkgsrc . ^{[ 116 ]} El soporte del kernel para USER_LTD— necesario para WoW64 — fue aportado por Maxime Villard en 2017, ^{[ 117 ]} permitiendo que las aplicaciones Win32 se ejecuten en amd64 . ^{[ 118 ]} El puerto amd64 de wine para NetBSD fue completado por Naveen Narayanan como parte de GSoC 2019. ^{[ 119 ]}

La programación de scripts en el espacio del kernel con el lenguaje de programación Lua se agregó en NetBSD 7.0. ^{[ 120 ]} El lenguaje Lua (es decir, su intérprete y bibliotecas estándar) fue portado inicialmente por Lourival Vieira Neto al kernel de NetBSD durante GSoC 2010 y ha experimentado varias mejoras desde entonces. ^{[ 121 ]} El conjunto de pruebas de Lua (espacio de usuario) se portó a Lua del kernel de NetBSD durante GSoC 2015. ^{[ 122 ]}

Existen dos diferencias principales entre Lua en el espacio de usuario y en el espacio del kernel: Lua en el espacio del kernel no admite números de coma flotante ; por lo tanto, solo están disponibles los enteros de Lua. ^{[ 123 ]} Tampoco ofrece soporte completo para las bibliotecas del espacio de usuario que dependen del sistema operativo (por ejemplo, io y os ). Guilherme Salazar desarrolló una implementación de ejemplo de enlaces de E/S (sistemas de archivos y sockets ) para Lua en el espacio del kernel. ^{[ 124 ]}

Las posibles aplicaciones del intérprete del kernel de Lua incluyen la integración de extensiones para el filtro de paquetes NPF , ^{[ 125 ] [ 126 ]} y la creación de un entorno aislado de aplicaciones en el kernel basado en kauth(9), con políticas de entorno aislado proporcionadas como scripts de Lua. ^{[ 127 ]}

NetBSD proporciona un depurador de kernel minimalista — DDB(4) — que se invoca por defecto siempre que el kernel pudiera provocar un pánico. ^{[ 128 ]} DDB permite inspeccionar procesos e hilos, investigar interbloqueos , obtener un rastreo de pila y generar un volcado de memoria del kernel para su posterior análisis. ^{[ 129 ]}

La comprobación de consistencia estricta se habilita compilando el kernel con la opción DIAGNOSTIC. Esto provocará que el kernel falle si se detecta corrupción en las estructuras de datos internas (por ejemplo, desreferenciación de puntero NULL del kernel). ^{[ 130 ]}

NetBSD también admite una variedad de funciones de detección de errores en el núcleo, ^{[ 131 ]} incluyendo sanitizadores de código (comportamiento indefinido, direcciones, hilos, sanitizadores de memoria), ^{[ 132 ] [ 133 ]} un sistema de detección de divulgación de memoria del núcleo (KLEAK) ^{[ 134 ]} y un subsistema de diagnóstico del núcleo llamado heartbeat(9). ^{[ 135 ]}

Los módulos del kernel cargables han sido compatibles con NetBSD desde la versión 0.9. La interfaz original lkm(4) ^{[ 136 ]} escrita por Terry Lambert fue reemplazada por el nuevo subsistema modules(7) ^{[ 137 ]} , que admite el manejo de dependencias entre módulos y la carga de módulos del kernel bajo demanda. ^{[ 138 ]}

Los nuevos módulos solo se pueden cargar cuando el nivel de seguridad es menor o igual a cero, o si el núcleo se compiló con la opción INSECURE, debido a problemas de seguridad relacionados con la falta de protección de memoria entre los módulos y el resto del núcleo.

Cada módulo del kernel debe definir sus metadatos a través de la macro C MODULE(class, name, required)e implementar una función MODNAME_modcmd functionque el kernel llama para informar sobre eventos importantes relacionados con el módulo, como cuando el módulo se carga o se descarga. ^{[ 139 ]}

NetBSD utiliza un init al estilo BSD .

Se admite el uso de un ramdisk inicial , pero no está habilitado por defecto, ^{[ 140 ]} excepto para configuraciones específicas (por ejemplo, cifrado de raíz ). ^{[ 141 ]}

El marco rc.d(8), diseñado por Luke Mewburn ^{[ 142 ]} para NetBSD 1.5, ^{[ 143 ]} proporciona un sistema de gestión de servicios totalmente modular, que utiliza scripts de shell individuales para controlar los servicios, de forma similar a como lo hace System V , pero sin niveles de ejecución . ^{[ 144 ]} Cuando invoca /etc/rc//etc/rc.d mediante init(8), ejecuta los scripts ubicados en el directorio. El orden en que se ejecutan los scripts lo determina la utilidad rcorder(8), basándose en los requisitos indicados en las etiquetas de dependencia que se encuentran dentro de cada script. ^{[ 145 ]}

NetBSD cuenta con un marco de monitoreo de hardware nativo desde 1999/2000. En 2003, sirvió de inspiración para el marco sysctl hw.sensors de OpenBSD cuando algunos controladores de NetBSD se estaban portando a OpenBSD. ^{[ 146 ]}

A fecha de marzo de 2019 NetBSD tenía cerca de 85 controladores de dispositivos que exportaban datos a través de la API del marco envsys. Desde la revisión de 2007, la serialización de datos entre el kernel y el espacio de usuario se realiza a través de listas de propiedades XML con la ayuda de proplib(3) de NetBSD .

La API del kernel de audio(4) de NetBSD ^{[ 147 ]} , modelada a partir de la pila de sonido de SunOS (SADA), ^{[ 148 ]} proporciona al mismo tiempo una capa de interfaz de programación uniforme sobre diferentes controladores de hardware de audio subyacentes y un backend para que lo utilicen diferentes bibliotecas de sonido ( SDL , PortAudio , Mozilla cubeb ).

Las aplicaciones pueden interactuar directamente con el nodo del dispositivo /dev/audio mediante una serie de llamadas ioctl especificadas en el archivo de cabecera sys/audioio.h . La información del dispositivo de audio se puede consultar con la llamada ioctl. Reproducir y grabar sonido implica abrir /dev/audio para operaciones de lectura y escritura y pasar una estructura al kernel. Esto reduce la latencia de audio y el uso de la CPU en comparación con el uso de capas de abstracción adicionales (otras bibliotecas de sonido o servidores de sonido ). ^{[ 149 ]}AUDIO_GETDEVaudio_info

La pila de audio se rediseñó en NetBSD 8.0 para proporcionar un motor de mezcla de software en el núcleo , con soporte para canales virtuales; ^{[ 150 ]} esto permite que más de un proceso reproduzca o grabe audio al mismo tiempo.

El archivo de cabecera soundcard.h y la biblioteca libossaudio ^{[ 151 ]} proporcionan un modo de compatibilidad para la API OSS , que internamente operan utilizando la interfaz de audio nativa tipo Sun.

NetBSD incluye soporte MIDI integrado a través del sistema midi(4) ^{[ 152 ]} independiente de la máquina .