Align with new uci config name: 'deviceinfo' -> 'reboots'
Compare changes
@@ -4,18 +4,18 @@ In TR-181 version 2.18, a new object, Device.DeviceInfo.Reboots, was introduced
@@ -4,18 +4,18 @@ In TR-181 version 2.18, a new object, Device.DeviceInfo.Reboots, was introduced
Currently, there is no standard configuration mapping to this object. However, we propose introducing a custom config called `sysmngr` to manage this information effectively.
The idea is to maintain a 1-to-1 mapping between the parameters and UCI config. To achieve this, we need to create an `init.d` service script that generates a UCI section each time the start_service() function is called. Essentially, when the start_service() function is executed, it will check the `/tmp/reset_reason` file for specific markers, such as (reset reason) and (reset triggered), to identify the cause of the last boot. And based on these markers, it will calculate the required counter for data model parameters and commit the changes in `sysmngr.deviceinfo` section. Furthermore, if necessary, it will create a UCI reboot section by checking `sysmngr.deviceinfo.max_reboot_entries` and adjusting the config accordingly.
The idea is to maintain a 1-to-1 mapping between the parameters and UCI config. To achieve this, we need to create an `init.d` service script that generates a UCI section each time the start_service() function is called. Essentially, when the start_service() function is executed, it will check the `/tmp/reset_reason` file for specific markers, such as (reset reason) and (reset triggered), to identify the cause of the last boot. And based on these markers, it will calculate the required counter for data model parameters and commit the changes in `sysmngr.reboots` section. Furthermore, if necessary, it will create a UCI reboot section by checking `sysmngr.reboots.max_reboot_entries` and adjusting the config accordingly.
This approach ensures that the data model maps directly to UCI config as closely as possible, eliminating the need for any adjustments at the data model layer.
- Device.DeviceInfo.Reboots.BootCount: Maps to sysmngr.deviceinfo.boot_count. This value is determined based on the marker (reset triggered: defaultreset) defined in `/tmp/reset_reason` file.
- Device.DeviceInfo.Reboots.CurrentVersionBootCount: Maps to sysmngr.deviceinfo.curr_version_boot_count. This value is determined based on the marker (reset triggered: upgrade) defined in `/tmp/reset_reason` file.
- Device.DeviceInfo.Reboots.WatchdogBootCount: Maps to sysmngr.deviceinfo.watchdog_boot_count. This value is determined based on the marker (reset reason: WATCHDOG) defined in `/tmp/reset_reason` file.
- Device.DeviceInfo.Reboots.ColdBootCount: Maps to sysmngr.deviceinfo.cold_boot_count. This value is determined based on the marker (reset reason: POR_RESET) defined in `/tmp/reset_reason` file.
- Device.DeviceInfo.Reboots.WarmBootCount: Maps to sysmngr.deviceinfo.warm_boot_count. This value is determined based on the marker (reset reason: POR_RESET) defined in `/tmp/reset_reason` file.
- Device.DeviceInfo.Reboots.MaxRebootEntries: Maps to sysmngr.deviceinfo.max_reboot_entries. Possible values include {-1, 0, etc..}. Each case will be handled internally by bbfdm and default value is 3 and maximum reboot entry supported is 255.
- Device.DeviceInfo.Reboots.RebootNumberOfEntries: This is an internal bbfdm mechanism used to count the number of reboot entries.
- Device.DeviceInfo.Reboots.RemoveAllReboots(): An internal bbfdm API to remove all reboot sections.
@@ -34,7 +34,7 @@ Below is an example of the configuration file:
@@ -34,7 +34,7 @@ Below is an example of the configuration file: