Currently, the "Battery" output only displays the main battery in the system, which is determined at compile-time. It ignores all of the other entries in the power_supply folder, some of which the user may care about.
If we add support for multiple batteries, I believe the batteries would have to be discovered at runtime rather than at compile-time. I have a Bluetooth keyboard which I use on and off throughout the day; this means that its battery appears and disappears from the power_supply folder.
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-power
Inside each subdirectory in power_supply, there is a file called type. We can use the contents of this file to determine which ones are truly batteries.
The contents of the file can be one of the following:
1) "Battery"
2) "UPS"
3) "Mains"
4) "USB"
On my system, I have a subdirectory called AC of type Mains. By checking against the type file, we would be able to filter this out.
https://www.kernel.org/doc/Documentation/power/power_supply_class.txt
Inside each battery subdirectory, there is a file called model_name. The contents of this file could be used to whitelist/blacklist battery entries in the configuration. However, I am not sure how we would make this whitelisting/blacklisting user-friendly.
To implement this, we would list the subdirectories in power_supply and filter out the ones that do not have Battery in their type file. For each remaining subdirectory, we would do what we are currently doing, just with BATTERY_DIRECTORY substituted with the path of that subdirectory. However, this approach would require some reworking of the current code.
Approach 1
In order to have one battery function handle all of the subdirectories in power_supply, one approach would be to have every function return a char** and an int holding the number of returns. One problem with this is that it would add unnecessary overhead to all of the other functions that only return 1 value.
The batteries would have to be named according to their model_name, so that would be another issue. Currently, the labels are determined at compile-time. If we want the battery function to work like this, the function itself would have to have control of the label, which would be another refactor.
Approach 2
A different approach that would require way less refactoring would be to have different functions for printing out each nth battery. With this approach, the model_name issue still persists, but we no longer have the issue of multiple returns from one function.
General
One thing we could do to reduce overhead is cache the output of ls and which subdirectories are batteries. In consecutive runs, we would run ls and see if the output equaled the cached version. If so, we would be able to skip the filtering step. However, the work involved in reading the cache and comparing the output of ls could be greater than just filtering them out each time.
Currently, the "Battery" output only displays the main battery in the system, which is determined at compile-time. It ignores all of the other entries in the
power_supplyfolder, some of which the user may care about.If we add support for multiple batteries, I believe the batteries would have to be discovered at runtime rather than at compile-time. I have a Bluetooth keyboard which I use on and off throughout the day; this means that its battery appears and disappears from the
power_supplyfolder.https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-power Inside each subdirectory in
power_supply, there is a file calledtype. We can use the contents of this file to determine which ones are truly batteries. The contents of the file can be one of the following: 1) "Battery" 2) "UPS" 3) "Mains" 4) "USB"On my system, I have a subdirectory called
ACof typeMains. By checking against thetypefile, we would be able to filter this out.https://www.kernel.org/doc/Documentation/power/power_supply_class.txt Inside each battery subdirectory, there is a file called
model_name. The contents of this file could be used to whitelist/blacklist battery entries in the configuration. However, I am not sure how we would make this whitelisting/blacklisting user-friendly.To implement this, we would list the subdirectories in
power_supplyand filter out the ones that do not haveBatteryin theirtypefile. For each remaining subdirectory, we would do what we are currently doing, just with BATTERY_DIRECTORY substituted with the path of that subdirectory. However, this approach would require some reworking of the current code.Approach 1
In order to have one battery function handle all of the subdirectories in
power_supply, one approach would be to have every function return achar**and anintholding the number of returns. One problem with this is that it would add unnecessary overhead to all of the other functions that only return 1 value.The batteries would have to be named according to their
model_name, so that would be another issue. Currently, the labels are determined at compile-time. If we want the battery function to work like this, the function itself would have to have control of the label, which would be another refactor.Approach 2
A different approach that would require way less refactoring would be to have different functions for printing out each nth battery. With this approach, the
model_nameissue still persists, but we no longer have the issue of multiple returns from one function.General
One thing we could do to reduce overhead is cache the output of
lsand which subdirectories are batteries. In consecutive runs, we would runlsand see if the output equaled the cached version. If so, we would be able to skip the filtering step. However, the work involved in reading the cache and comparing the output oflscould be greater than just filtering them out each time.