[pmon] Port syseepromd to Rust by ganglyu · Pull Request #917 · sonic-net/sonic-platform-daemons

ganglyu · 2026-09-30T05:23:59Z

Why I did it

The pmon daemons move to Rust while they keep reaching the hardware
through each vendor's Python platform API, over the facade that
sonic-platform-common generates (sonic-net/sonic-platform-common#768).
This PR ports syseepromd.

Work item tracking

Microsoft ADO (number only):

How I did it

crates/syseepromd is a port of sonic-syseepromd/scripts/syseepromd. It
writes the same EEPROM_INFO entries as the Python daemon and logs the
same messages. Where it departs from Python on purpose, a comment at
that spot says so.
It builds on crates/pmon-common and adds the binary package
sonic-syseepromd-rs to the workspace's source package.
The Python syseepromd is unchanged. A platform picks one of the two in
pmon_daemon_control.json.

It is based on #915, which adds the Rust
workspace, crates/pmon-common and thermalctld; until #915 merges, this
PR also shows that commit. It does not depend on the other daemons,
which are ported in PRs of their own: psud (#916), pcied (#918),
stormond (#919), chassisd (#920).

How to verify it

Build an image whose pmon runs the Rust daemons and run the sonic-mgmt
platform tests (tests/platform_tests) on it.

Which release branch to backport (provide reason below if selected)

Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO):
Failure type:

Tested branch

Test result

master: the sonic-mgmt platform tests pass with the Rust pmon daemons
running.

Description for the changelog

Add a Rust port of syseepromd.

Link to config_db schema for YANG module changes

N/A

A picture of a cute animal (not mandatory but encouraged)

azure-pipelines · 2026-09-30T05:24:09Z

Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run.

mssonicbld · 2026-09-30T05:24:20Z

/azp run

azure-pipelines · 2026-09-30T05:24:30Z

Azure Pipelines: Successfully started running 1 pipeline(s).

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports pcied. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/pcied is a port of sonic-pcied/scripts/pcied. It writes the same PCIE_DEVICE and PCIE_DEVICES entries as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-pcied-rs to the workspace's source package. - The Python pcied is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: psud (sonic-net#916), syseepromd (sonic-net#917), stormond (sonic-net#919), chassisd (sonic-net#920). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of pcied. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports psud. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/psud is a port of sonic-psud/scripts/psud. It writes the same PSU_INFO, the PSU half of FAN_INFO, the PSU tray LEDs and, on a modular chassis, the power budget in CHASSIS_INFO as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-psud-rs to the workspace's source package. - The Python psud is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: syseepromd (sonic-net#917), pcied (sonic-net#918), stormond (sonic-net#919), chassisd (sonic-net#920). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of psud. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports chassisd. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/chassisd is a port of sonic-chassisd/scripts/chassisd. It writes the same CHASSIS_TABLE, CHASSIS_MODULE_TABLE and CHASSIS_MIDPLANE_TABLE entries, the ASIC tables and, on a SmartSwitch, DPU_STATE and the DPU reboot causes as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-chassisd-rs to the workspace's source package. - The Python chassisd is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: psud (sonic-net#916), syseepromd (sonic-net#917), pcied (sonic-net#918), stormond (sonic-net#919). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of chassisd. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports stormond. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/stormond is a port of sonic-stormond/scripts/stormond. It writes the same STORAGE_INFO entries as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-stormond-rs to the workspace's source package. - The Python stormond is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: psud (sonic-net#916), syseepromd (sonic-net#917), pcied (sonic-net#918), chassisd (sonic-net#920). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of stormond. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

mssonicbld · 2026-09-30T05:25:07Z

/azp run

azure-pipelines · 2026-09-30T05:25:17Z

Azure Pipelines: Successfully started running 1 pipeline(s).

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768, which this PR depends on). This PR adds the Rust workspace, the code the Rust daemons share, and the first daemon. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/thermalctld is a port of sonic-thermalctld/scripts/thermalctld. It writes the same TEMPERATURE_INFO, FAN_INFO, FAN_DRAWER_INFO and PHYSICAL_ENTITY_INFO entries and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - crates/pmon-common holds what the Rust daemons share: the STATE_DB tables and their mock, Python str() formatting, the platform_env.conf readers, the poll cadence and logging. - Comments cite the Python code by symbol, for example thermalctld:TemperatureUpdater._collect_thermals. A pmon-common test fails if a cited symbol no longer exists or if a comment cites a line number. - debian/ builds the workspace as one source package. This PR adds its first binary package, sonic-thermalctld-rs. cargo test runs in the package build. - The workspace takes platform-api and platform-provider from sonic-platform-common, and swss-common from sonic-swss-common, as git dependencies, the way sonic-swss and sonic-dash-ha take swss-common. Cargo.lock pins the commits. sonic-buildimage builds against its own submodules instead: it gives debian/rules a cargo config whose [patch] entries point at them, so the PyO3 bridge matches the Python facade in the same image. - azure-pipelines.yml builds, lints and tests the Rust workspace with line coverage, so the diff coverage check counts the Rust code. - The Python thermalctld is unchanged. A platform picks one of the two in pmon_daemon_control.json. This is the first of six PRs. The other five each port one daemon on top of this one and do not depend on each other, so this PR merges first and they follow in any order: - sonic-net#916: psud - sonic-net#917: syseepromd - sonic-net#918: pcied - sonic-net#919: stormond - sonic-net#920: chassisd #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of thermalctld, and the crate the Rust pmon daemons share. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports syseepromd. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/syseepromd is a port of sonic-syseepromd/scripts/syseepromd. It writes the same EEPROM_INFO entries as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-syseepromd-rs to the workspace's source package. - The Python syseepromd is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: psud (sonic-net#916), pcied (sonic-net#918), stormond (sonic-net#919), chassisd (sonic-net#920). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of syseepromd. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports psud. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/psud is a port of sonic-psud/scripts/psud. It writes the same PSU_INFO, the PSU half of FAN_INFO, the PSU tray LEDs and, on a modular chassis, the power budget in CHASSIS_INFO as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-psud-rs to the workspace's source package. - The Python psud is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: syseepromd (sonic-net#917), pcied (sonic-net#918), stormond (sonic-net#919), chassisd (sonic-net#920). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of psud. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports stormond. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/stormond is a port of sonic-stormond/scripts/stormond. It writes the same STORAGE_INFO entries as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-stormond-rs to the workspace's source package. - The Python stormond is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: psud (sonic-net#916), syseepromd (sonic-net#917), pcied (sonic-net#918), chassisd (sonic-net#920). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of stormond. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports chassisd. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/chassisd is a port of sonic-chassisd/scripts/chassisd. It writes the same CHASSIS_TABLE, CHASSIS_MODULE_TABLE and CHASSIS_MIDPLANE_TABLE entries, the ASIC tables and, on a SmartSwitch, DPU_STATE and the DPU reboot causes as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-chassisd-rs to the workspace's source package. - The Python chassisd is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: psud (sonic-net#916), syseepromd (sonic-net#917), pcied (sonic-net#918), stormond (sonic-net#919). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of chassisd. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports pcied. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/pcied is a port of sonic-pcied/scripts/pcied. It writes the same PCIE_DEVICE and PCIE_DEVICES entries as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-pcied-rs to the workspace's source package. - The Python pcied is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: psud (sonic-net#916), syseepromd (sonic-net#917), stormond (sonic-net#919), chassisd (sonic-net#920). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of pcied. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

mssonicbld · 2026-09-30T09:12:46Z

/azp run

azure-pipelines · 2026-09-30T09:12:56Z

Azure Pipelines: Successfully started running 1 pipeline(s).

#### Why I did it The pmon daemons thermalctld, psud, chassisd, stormond, pcied and syseepromd move to Rust while they keep reaching the hardware through each vendor's Python platform API. That API returns platform objects and stores callbacks, so a Rust daemon would cross the language boundary once per attribute per device. sonic-platform-common now declares a flat facade and generates the Python facade, the Rust trait and the PyO3 bridge from it, so a row crosses once and the two sides cannot disagree. This PR builds the Rust daemons into the image and lets each platform switch to them. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - rules/sonic-pmon-daemons-rs.mk builds the Rust workspace in sonic-platform-daemons as one source package with six binary packages, sonic-<daemon>-rs, plus their dbgsym packages. rules/sonic-pmon-daemons-rs.dep tracks its inputs. - rules/docker-platform-monitor.mk installs them in the pmon container beside the Python daemons. - The daemons' workspace takes the platform API crates and swss-common from git, at the commits its Cargo.lock pins. rules/sonic-pmon-daemons-rs.cargo.toml points them at src/sonic-platform-common and src/sonic-swss-common instead, so the Rust daemons build from the same commits as the rest of the image. The .mk passes it to the package build. - docker-pmon.supervisord.conf.j2 starts the Rust binary for a daemon when the platform's pmon_daemon_control.json sets use_rust_<daemon>. platform_api_<daemon> chooses the platform API implementation, pyo3 by default, and is passed on the daemon's command line. - The Mellanox switch and BlueField platforms turn the Rust daemons on. Every other platform keeps the Python daemons. - The build needs src/sonic-platform-common and src/sonic-platform-daemons at commits that carry the facade and the Rust daemons. This PR does not move them; the submodule update follows once the PRs below merge. Submodule PRs, to merge first: - sonic-net/sonic-platform-common#768: the facade and its crates - sonic-net/sonic-platform-daemons#915: the Rust workspace, pmon-common and thermalctld - then, in any order, one daemon each: sonic-net/sonic-platform-daemons#916 (psud), sonic-net/sonic-platform-daemons#917 (syseepromd), sonic-net/sonic-platform-daemons#918 (pcied), sonic-net/sonic-platform-daemons#919 (stormond), sonic-net/sonic-platform-daemons#920 (chassisd) #### How to verify it Build the image and run the sonic-mgmt platform tests (tests/platform_tests) on a platform that turns the Rust daemons on. In the pmon container, supervisorctl status lists the daemons, and ps shows them running as /usr/bin/<daemon>-rs. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Run thermalctld, psud, chassisd, stormond, pcied and syseepromd in Rust on the platforms that turn them on. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports psud. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/psud is a port of sonic-psud/scripts/psud. It writes the same PSU_INFO, the PSU half of FAN_INFO, the PSU tray LEDs and, on a modular chassis, the power budget in CHASSIS_INFO as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-psud-rs to the workspace's source package. - The Python psud is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: syseepromd (sonic-net#917), pcied (sonic-net#918), stormond (sonic-net#919), chassisd (sonic-net#920). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of psud. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports chassisd. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/chassisd is a port of sonic-chassisd/scripts/chassisd. It writes the same CHASSIS_TABLE, CHASSIS_MODULE_TABLE and CHASSIS_MIDPLANE_TABLE entries, the ASIC tables and, on a SmartSwitch, DPU_STATE and the DPU reboot causes as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-chassisd-rs to the workspace's source package. - The Python chassisd is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: psud (sonic-net#916), syseepromd (sonic-net#917), pcied (sonic-net#918), stormond (sonic-net#919). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of chassisd. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports psud. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/psud is a port of sonic-psud/scripts/psud. It writes the same PSU_INFO, the PSU half of FAN_INFO, the PSU tray LEDs and, on a modular chassis, the power budget in CHASSIS_INFO as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-psud-rs to the workspace's source package. - The Python psud is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: syseepromd (sonic-net#917), pcied (sonic-net#918), stormond (sonic-net#919), chassisd (sonic-net#920). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of psud. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768, which this PR depends on). This PR adds the Rust workspace, the code the Rust daemons share, and the first daemon. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/thermalctld is a port of sonic-thermalctld/scripts/thermalctld. It writes the same TEMPERATURE_INFO, FAN_INFO, FAN_DRAWER_INFO and PHYSICAL_ENTITY_INFO entries and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - crates/pmon-common holds what the Rust daemons share: the STATE_DB tables and their mock, Python str() formatting, the platform_env.conf readers, the poll cadence and logging. - Comments cite the Python code by symbol, for example thermalctld:TemperatureUpdater._collect_thermals. A pmon-common test fails if a cited symbol no longer exists or if a comment cites a line number. - debian/ builds the workspace as one source package. This PR adds its first binary package, sonic-thermalctld-rs. cargo test runs in the package build. - The workspace takes platform-api and platform-provider from sonic-platform-common, and swss-common from sonic-swss-common, as git dependencies, the way sonic-swss and sonic-dash-ha take swss-common. Cargo.lock pins the commits. sonic-buildimage builds against its own submodules instead: it gives debian/rules a cargo config whose [patch] entries point at them, so the PyO3 bridge matches the Python facade in the same image. - azure-pipelines.yml builds, lints and tests the Rust workspace with line coverage, so the diff coverage check counts the Rust code. - The Python thermalctld is unchanged. A platform picks one of the two in pmon_daemon_control.json. This is the first of six PRs. The other five each port one daemon on top of this one and do not depend on each other, so this PR merges first and they follow in any order: - sonic-net#916: psud - sonic-net#917: syseepromd - sonic-net#918: pcied - sonic-net#919: stormond - sonic-net#920: chassisd #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of thermalctld, and the crate the Rust pmon daemons share. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

mssonicbld · 2026-10-19T03:27:05Z

/azp run

azure-pipelines · 2026-10-19T03:27:14Z

Azure Pipelines: Successfully started running 1 pipeline(s).

#### Why I did it The pmon daemons thermalctld, psud, chassisd, stormond, pcied and syseepromd move to Rust while they keep reaching the hardware through each vendor's Python platform API. That API returns platform objects and stores callbacks, so a Rust daemon would cross the language boundary once per attribute per device. sonic-platform-common now declares a flat facade and generates the Python facade, the Rust trait and the PyO3 bridge from it, so a row crosses once and the two sides cannot disagree. This PR builds the Rust daemons into the image and lets each platform switch to them. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - rules/sonic-pmon-daemons-rs.mk builds the Rust workspace in sonic-platform-daemons as one source package with six binary packages, sonic-<daemon>-rs, plus their dbgsym packages. rules/sonic-pmon-daemons-rs.dep tracks its inputs. - rules/docker-platform-monitor.mk installs them in the pmon container beside the Python daemons. - The daemons' workspace takes the platform API crates and swss-common from git, at the commits its Cargo.lock pins. rules/sonic-pmon-daemons-rs.cargo.toml points them at src/sonic-platform-common and src/sonic-swss-common instead, so the Rust daemons build from the same commits as the rest of the image. The .mk passes it to the package build. - docker-pmon.supervisord.conf.j2 starts the Rust binary for a daemon when the platform's pmon_daemon_control.json sets use_rust_<daemon>. platform_api_<daemon> chooses the platform API implementation, pyo3 by default, and is passed on the daemon's command line. - The Mellanox switch and BlueField platforms turn the Rust daemons on. Every other platform keeps the Python daemons. - The build needs src/sonic-platform-common and src/sonic-platform-daemons at commits that carry the facade and the Rust daemons. This PR does not move them; the submodule update follows once the PRs below merge. Submodule PRs, to merge first: - sonic-net/sonic-platform-common#768: the facade and its crates - sonic-net/sonic-platform-daemons#915: the Rust workspace, pmon-common and thermalctld - then, in any order, one daemon each: sonic-net/sonic-platform-daemons#916 (psud), sonic-net/sonic-platform-daemons#917 (syseepromd), sonic-net/sonic-platform-daemons#918 (pcied), sonic-net/sonic-platform-daemons#919 (stormond), sonic-net/sonic-platform-daemons#920 (chassisd) #### How to verify it Build the image and run the sonic-mgmt platform tests (tests/platform_tests) on a platform that turns the Rust daemons on. In the pmon container, supervisorctl status lists the daemons, and ps shows them running as /usr/bin/<daemon>-rs. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Run thermalctld, psud, chassisd, stormond, pcied and syseepromd in Rust on the platforms that turn them on. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports psud. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/psud is a port of sonic-psud/scripts/psud. It writes the same PSU_INFO, the PSU half of FAN_INFO, the PSU tray LEDs and, on a modular chassis, the power budget in CHASSIS_INFO as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-psud-rs to the workspace's source package. - The Python psud is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: syseepromd (sonic-net#917), pcied (sonic-net#918), stormond (sonic-net#919), chassisd (sonic-net#920). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of psud. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

#### Why I did it The pmon daemons move to Rust while they keep reaching the hardware through each vendor's Python platform API, over the facade that sonic-platform-common generates (sonic-net/sonic-platform-common#768). This PR ports syseepromd. ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it - crates/syseepromd is a port of sonic-syseepromd/scripts/syseepromd. It writes the same EEPROM_INFO entries as the Python daemon and logs the same messages. Where it departs from Python on purpose, a comment at that spot says so. - It builds on crates/pmon-common and adds the binary package sonic-syseepromd-rs to the workspace's source package. - The Python syseepromd is unchanged. A platform picks one of the two in pmon_daemon_control.json. It is based on sonic-net#915, which adds the Rust workspace, crates/pmon-common and thermalctld; until sonic-net#915 merges, this PR also shows that commit. It does not depend on the other daemons, which are ported in PRs of their own: psud (sonic-net#916), pcied (sonic-net#918), stormond (sonic-net#919), chassisd (sonic-net#920). #### How to verify it Build an image whose pmon runs the Rust daemons and run the sonic-mgmt platform tests (tests/platform_tests) on it. #### Which release branch to backport (provide reason below if selected) - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO): Failure type: #### Tested branch - [x] master - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 - [ ] 202512 - [ ] 202605 - [ ] 202608 - [ ] N/A #### Test result master: the sonic-mgmt platform tests pass with the Rust pmon daemons running. #### Description for the changelog Add a Rust port of syseepromd. #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Geoffrey Lyu <glv@nvidia.com>

mssonicbld · 2026-10-19T04:49:54Z

/azp run

azure-pipelines · 2026-10-19T04:50:04Z