El marco envsys es un marco de sensores de monitoreo de hardware a nivel de kernel en NetBSD . Al 4 de marzo de 2019 , cerca de 85 controladores de dispositivos utilizan el marco para exportar varios sensores de monitoreo ambiental , como lo demuestran las referencias del símbolo [1] dentro de la ruta de NetBSD; con sensores de temperatura , siendo [2] el tipo con mayor probabilidad de ser exportado por cualquier controlador determinado. [3] : 32 sensores se registran en el kernel a través de API. [4] El consumo y el monitoreo de los sensores desde el área de usuario se realiza con la ayuda de la utilidad a través del archivo del pseudodispositivo , [5] el demonio de administración de energía que responde a los eventos del kernel ejecutando scripts desde , [6] [7] así como herramientas de terceros como GKrellM de pkgsrc .[actualizar]sysmon_envsys_registersysENVSYS_STEMP sysmon_envsys(9)envstatproplib(3)ioctl(2)/dev/sysmon powerd/etc/powerd/scripts/symon
El marco permite al usuario modificar los límites de monitoreo especificados por el controlador y que el controlador realice el monitoreo de los sensores en el espacio del kernel, o incluso programar un chip de hardware para realizar el monitoreo del sistema automáticamente. [3] : §7.1 Se definen dos niveles de límites: crítico y de advertencia , los cuales se extienden adicionalmente a una categorización superior e inferior . [3] : §7.1 Si se cruzan los umbrales límite, se puede generar un evento del kernel, que se puede capturar en el área de usuario al powerdejecutar un script de usuario predefinido. [6] [7] En comparación, en hw.sensors de OpenBSD , el monitoreo de los valores definidos por el usuario se realiza en el espacio de usuario mediante sensorsd.
A partir de 2019 [actualizar], el marco en sí no facilita el control del ventilador de la computadora , aunque los controladores aún podrían implementar la interfaz con las capacidades de control de ventilador de sus chips a través de otros medios, por ejemplo, a través de una interfaz sysctl específica del controlador , que es el enfoque adoptado. por el dbcool(4)conductor. [8] Sin embargo, a los controladores de los chips Super I/O más populares les gusta lm(4)y itesio(4)no implementan ningún control de ventilador (de hecho, históricamente, en todos OpenBSD, NetBSD y DragonFly, estos controladores ni siquiera informan sobre la función). ciclo de los ventiladores: solo se informan los valores de RPM reales). [9] [10]
El marco sufrió dos revisiones importantes: la primera versión envsys.hse comprometió el 15 de diciembre de 1999 ; con página de manual a continuación el 27 de febrero de 2000 . Entre 2000 y 2007, la página del manual de envsys(4) en NetBSD indicaba que "la API es experimental" y que "la API completa debería ser reemplazada por un sysctl(8)", "en caso de que se desarrolle alguna"; [11] [12] se puede observar que en 2003 este fue el enfoque exacto adoptado por OpenBSD con sysctl hw.sensors cuando algunos de los controladores envsys(4) fueron portados a OpenBSD. [3] : §6.1envsys.4
La segunda revisión se produjo el 1 de julio de 2007 . La serialización con el área de usuario se reimplementó usando listas de propiedades con la ayuda de la nueva biblioteca proplib(3) de NetBSD (la capa de transporte subyacente entre el núcleo y el área de usuario aún se realiza a través de ioctl ). [13] [3]
El marco envsys fue el precursor del marco sysctl hw.sensors de OpenBSD en 2003, y muchos controladores, así como algunos tipos de sensores, se han trasladado entre NetBSD y OpenBSD. El soporte para sensores de drivetipo se agregó a NetBSD el 1 de mayo de 2007 , similar al drivetipo en OpenBSD , que fue al mismo tiempo cuando bio(4) y bioctl fueron portados de OpenBSD a NetBSD. [3] : §7.1
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
#define _PATH_SYSMON "/dev/sysmon"Esta API es experimental y puede quedar obsoleta en cualquier momento... Esta API completa debería ser reemplazada por una interfaz sysctl(8) o un mecanismo de eventos del kernel, en caso de que se desarrolle uno.