El marco envsys es un marco de sensores de monitoreo de hardware a nivel de kernel en NetBSD . A partir del 4 de marzo de 2019 , el marco es utilizado por cerca de 85 controladores de dispositivos para exportar varios sensores de monitoreo ambiental , como lo evidencian las referencias del símbolo [1] dentro de la ruta de NetBSD; con sensores de temperatura , , [2] siendo el tipo más probable de ser exportado por cualquier controlador dado. [3] : 32 sensores se registran con el kernel a través de API. [4] El consumo y monitoreo de sensores desde el espacio de usuario se realiza con la ayuda de la utilidad a través del archivo pseudo-dispositivo , [5] el demonio de administración de energía que responde a eventos del kernel ejecutando scripts desde , [6] [7] así como herramientas de terceros como y 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 núcleo, o incluso programar un chip de hardware para que realice el monitoreo del sistema automáticamente. [3] : §7.1 Se definen dos niveles de límites: crítico y advertencia , los cuales se extienden adicionalmente a una categorización por encima y por debajo . [3] : §7.1 Si se cruzan los umbrales límite, se puede generar un evento de núcleo, que se puede capturar en el espacio de usuario mediante powerdpara ejecutar 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 del 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)controlador. [8] Sin embargo, los controladores de los chips Super I/Olm(4) más populares, como y itesio(4)no implementan ningún control de ventilador en absoluto (de hecho, históricamente, en todos los OpenBSD, NetBSD y DragonFly, estos controladores ni siquiera informan el ciclo de trabajo de los ventiladores, solo se informan los valores reales de RPM). [9] [10]
El marco de trabajo sufrió dos revisiones importantes: la primera versión envsys.hse envió el 15 de diciembre de 1999 ; con una página de manual posterior el 27 de febrero de 2000 . Entre 2000 y 2007, la página de manual para envsys(4) en NetBSD afirmaba que la "API es experimental", y que "la API entera debería ser reemplazada por un sysctl(8)", "en caso de que se desarrolle uno"; [11] [12] se puede notar que en 2003 este fue el enfoque exacto adoptado por OpenBSD con sysctl hw.sensors cuando algunos de los controladores de envsys(4) fueron portados a OpenBSD. [3] : §6.1envsys.4
La segunda revisión se realizó el 1 de julio de 2007 . La serialización con espacio de usuario se volvió a implementar utilizando 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 espacio de usuario todavía se realiza a través de ioctl ). [13] [3]
El marco de trabajo envsys fue el precursor del marco de trabajo sysctl hw.sensors de OpenBSD en 2003, y muchos controladores, así como algunos tipos de sensores, se han portado de ida y vuelta entre NetBSD y OpenBSD. El soporte para sensores de drivetipo se agregó a NetBSD el 1 de mayo de 2007 , de manera similar a drivetype en OpenBSD , que fue al mismo tiempo en que bio(4) y bioctl se portaron 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 núcleo, en caso de que se desarrolle uno.