naguam However I also think that if the type "battery" in "device-properties"/"device-class" does not define a standard definition for a battery of any driver, then this defeats the point of having that envsys abstraction on NetBSD's side.
No, that should be non-changeable data, reflecting the drivers setting SME_CLASS_BATTERY (which, I see that the old MacPPC battery driver isn't setting for some reason!)
naguam The default descriptions on a shared subset of the fields available seem to be the only common thing among battery drivers regarding the links you just provided.
You can just keep a table like I suggested.
naguam But in the examples INITDATA is not always done in order (but this may not matter if it is use enum as array indexes)
The enums are used as array indexes.
naguam n the powermac driver the ENUM you showed as an BAT_NSENSORS that is not sent into envsys the same way as the others.
Where is BAT_NSENSORS being being passed up to userspace? There's no need to do this...
That'll stop working if you:
a) change the sensor-index description (which you can do from userspace using either envstat or the code below), or,
b) try it on the MacPPC battery, where the description is Battery charge rather than charge, etc.
setenvprop.c
#include <prop/proplib.h>
#include <sys/envsys.h>
#include <sys/ioctl.h>
#include <err.h>
#include <errno.h>
#include <fcntl.h>
#include <paths.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int
main(void)
{
prop_dictionary_t global_dict, sensor_dict;
prop_array_t array;
prop_object_t obj;
int fd, error;
global_dict = prop_dictionary_create();
sensor_dict = prop_dictionary_create();
array = prop_array_create();
if (!prop_dictionary_set(global_dict, "acpibat0", array))
err(EINVAL, "prop_dictionary_set global");
obj = prop_string_create_nocopy("sensor5"); // "charge"
if (obj == NULL ||
!prop_dictionary_set(sensor_dict, "index", obj))
err(EINVAL, "sensor index");
prop_object_release(obj);
/* new description */
obj = prop_string_create_nocopy("チャージ"); // katakana now
if (obj == NULL ||
!prop_dictionary_set(sensor_dict, "description", obj))
err(EINVAL, "new description");
prop_object_release(obj);
if (!prop_array_add(array, sensor_dict))
err(EINVAL, "prop_array_add");
if ((fd = open(_PATH_SYSMON, O_RDWR)) == -1)
err(EXIT_FAILURE, "%s: open failed.", _PATH_SYSMON);
/* we're done, send the dictionary */
error = prop_dictionary_send_ioctl(global_dict,
fd,
ENVSYS_SETDICTIONARY);
prop_object_release(array);
prop_object_release(sensor_dict);
prop_object_release(global_dict);
(void)close(fd);
return error;
}
Where does envstat use sensor-index descriptions? (It shouldn't--it's just dumping the whole thing)
naguam What should I take into account in the end.
A table of driver/sensor-indexes is the only way I can think of making this robust. I doubt if the kernel devs. will change those indexes now.
naguam (I took inspiration on the existing Freebsd as well as golang version distatus for energy_rate units/management (I think the latter have a memory leak, because the mmap allocated by the kernel which is not handled by golang gc AFAIK is not munmaped))
Yeah, that was a bit of a pain to figure out, but, you only need to do that if you use the "raw" ioctl like I'm doing there (the idea being to parse the XML using expat). What you should do, instead, is call prop_dictionary_recv_ioctl(), then just release the dictionary using prop_object_release().
