bioctl

El controlador de pseudodispositivo bio(4) y la utilidad bioctl(8) para implementar una interfaz genérica de administración de volúmenes RAID en OpenBSD y NetBSD . ^{[ 1 ] [ 2 ]} La idea detrás de este software es similar a ifconfig , donde una sola utilidad del sistema operativo puede usarse para controlar cualquier controlador RAID usando una interfaz genérica , en lugar de tener que depender de muchas utilidades de administración RAID propietarias y personalizadas específicas para cada fabricante de hardware RAID. ^{[ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ]} Las características incluyen monitoreo del estado de salud de las matrices, control de identificación a través del parpadeo de los LED y administración de alarmas sonoras, y especificación de discos de reserva en caliente . Además, la configuración en OpenBSD también se delega a bioctl; mientras que la creación inicial de volúmenes y configuración de RAID de hardware se deja a la BIOS de la tarjeta como no esencial después de que el sistema operativo ya se ha iniciado. ^{[ 4 ]} La interfaz entre el kernel y el espacio de usuario se realiza a través de la llamada al sistema a través del pseudodispositivo .softraidioctl/dev/bio

El subsistema bio/bioctl se considera una parte importante en la defensa de OpenBSD de la documentación de hardware abierta, y el título de la versión 3.8 y la canción homónima se dedicaron al tema: Hackers of the Lost RAID . ^{[ 5 ] [ 8 ] [ 9 ]} El desarrollo tuvo lugar durante un período de controversia en el que Adaptec se negó a publicar la documentación de hardware adecuada que era necesaria para que el controlador aac(4) funcionara de manera confiable, lo que llevó a OpenBSD a deshabilitar el soporte para el controlador. ^{[ 9 ]}

In the commentary to the 3.8 release,^[9] the developers express the irony of hardware RAID controllers' supposed purpose of providing reliability, through redundancy and repair, whereas in reality many vendors expect system administrators to install and depend on huge binary blobs in order to be assess volume health and service their disk arrays. Specifically, OpenBSD is making a reference to the modus operandi of FreeBSD, where the documentation of the aac(4) driver for Adaptec specifically suggests enabling Linux compatibility layer in order to use the management utilities (where the documentation even fails to explain where exactly these utilities must be obtained from, or which versions would be compatible, evidently because the proprietary tools may have expired).^[10][11][12]

Likewise, OpenBSD developers intentionally chose to concentrate on supporting only the most basic features of each controller which are uniform across all the brands and variations; specifically, the fact that initial configuration of each controller must still be made through card BIOS was never kept secret from any bio/bioctl announcement.^[4][5] This can be contrasted with the approach taken by FreeBSD, for example, where individual utilities exist for several independent RAID drivers, and the interface of each utility is independent of one another; specifically, as of March 2019, FreeBSD includes separate device-specific utilities called mfiutil, mptutil, mpsutil/mprutil and sesutil,^{[13][14][15][16]}, each of which provides many options with at least subtle differences in the interface for configuration and management of the controllers, contributes to code bloat, not to mention any additional drivers for which no such tool even exists as open-source software at all.^[17] In OpenBSD 6.4 (2018), a dozen of drivers register with the bio framework.^[1]

La monitorización del estado de cada unidad lógica también se duplica en los marcos de monitorización de hardware y sus utilidades correspondientes en ambos sistemas donde bioctl está disponible: hw.sensors con sensorsd en OpenBSD ^{[ 4 ]} y sysmon envsys con envstat y powerd en NetBSD . ^{[ 18 ]} Por ejemplo, en OpenBSD desde la versión 4.2, el estado de los sensores de la unidad se puede monitorizar automáticamente simplemente iniciando sensorsd sin necesidad de ninguna configuración específica. ^{[ 19 ]} Con cada versión, se están convirtiendo más controladores para usar los marcos bio y sensors. ^{[ 20 ]}

En OpenBSD, tanto SCSI Enclosure Services (SES) ^{[ 21 ]} como SAF-TE ^{[ 22 ]} son ​​compatibles desde OpenBSD 3.8 (2005), ambos con parpadeo de LED a través de bio y bioctl (mediante la implementación de BIOCBLINKioctl ), lo que ayuda a los administradores del sistema a identificar dispositivos dentro de los gabinetes para dar servicio. Además, tanto los controladores SES como SAF-TE en OpenBSD ofrecen soporte para una combinación de sensores de temperatura y ventilador, PSU , cerradura de puerta e indicadores de alarma; todos estos datos de sensores auxiliares se exportan al marco hw.sensors en OpenBSD, ^{[ 4 ]} y se pueden monitorear a través de herramientas familiares como sysctl , SNMP y sensorsd .

A partir de 2019En NetBSD , todavía se utiliza un controlador SES/SAF-TE antiguo de la NASA del año 2000, que no está integrado con bio ni envsys , pero tiene sus propios archivos de dispositivo con una interfaz ioctl única , que incluye sus propias herramientas de espacio de usuario específicas para SCSI personalizadas; ^{[ 23 ] [ 24 ]} esta implementación antigua también estuvo disponible en OpenBSD entre 2000 y 2005, y se eliminó en 2005 (junto con sus herramientas de espacio de usuario) justo antes de que se introdujeran los nuevos controladores alternativos más ligeros basados ​​en bio y hw.sensors; SES y SAF-TE ahora se mantienen como dos controladores separados en OpenBSD, pero ya no requieren ninguna utilidad de espacio de usuario personalizada separada, lo que reduce la inflación del código y el número de líneas de código fuente .