Platform Services

The platform stack is the set of FBOSS daemons that manage the switch chassis rather than the forwarding ASIC: discovering hardware and loading drivers, reading sensors, controlling fans, tracking FRUs, and driving LEDs. They need no ASIC SDK and are built by the fboss_platform_services CMake target. This page explains how they identify the platform and find their configs, then covers each service's job, flags, and behavior.

Service	Job	Default port
`platform_manager`	Platform detection, BSP RPM and kernel modules, device discovery, `/run/devmap`	5975 (daemon mode)
`sensor_service`	Read sensors, serve and publish their values	5970
`fan_service`	Thermal control: compute and program fan PWM	5972
`data_corral_service`	FRU presence detection and presence LEDs	5971
`led_service`	Front-panel port LEDs	5930

Related utilities (weutil, fw_util, fixmyfboss, rma-showtech) are on Diagnostic Tools.

Platform Detection and Configs

How the Platform Name Is Determined

All platform services use PlatformNameLib:

If /var/facebook/fboss/platform_name exists, its content is the platform name (a cache).
Otherwise run dmidecode -s system-product-name, the product name the BIOS reports, and normalize it to upper case.
A few names are mapped: MINIPACK3 and MINIPACK3_MCB become MONTBLANC, MINIPACK3M and MINIPACK3M_MCB become MONTBLANCM, JANGA becomes JANGA800BIC, TAHAN becomes TAHAN800BC.
When the name is obtained from the BIOS, it can be written to the cache file.

If dmidecode fails, the name is unknown and the services that need a config fail. This is why vendors must make the platform type available through dmidecode (see the Meta switch architecture and BMC-Lite documents in the repo).

Note: Because of the cache, changing what dmidecode reports (for example after reprogramming the BIOS on a lab unit) has no effect until /var/facebook/fboss/platform_name is removed.

Where Configs Come From

Platform configs are JSON files in the repository, one directory per platform:

fboss/configs/platforms/<vendor>/<platform>/platform_stack/
├── platform_manager.json
├── sensor_service.json
├── fan_service.json
├── fw_util.json
├── led_manager.json
├── bsp_tests.json
└── rma_showtech.json

Vendors in the tree are accton, arista, celestica, cisco, nexthop, and generic (with sample and example_integrated_optics examples). At build time, platform_config_lib_config_generator embeds all these JSON files into the binaries (ConfigLib), so a deployed service carries every platform's config and picks its own by name (lower-cased). Some hardware variants reuse another platform's config through built-in aliases, for example wedge800cnhp uses wedge800cact, meru800biab and meru800biac use meru800bia, and m4052acti uses minipack3ba.

To use a different config without rebuilding, pass --config_file <path>. If it is empty (the default), the embedded default for the detected platform is used.

Note: The sensor_service and fan_service READMEs say to use --config to override the config. The flag the code defines (in config_lib/ConfigLib.cpp) is --config_file.

--run_in_netos (default false) selects the darwin_netos config instead of darwin on Darwin platforms.

platform_manager

PlatformManager generalizes low-level device setup so that the same code runs on every platform, with everything platform-specific in platform_manager.json (schema: fboss/platform/platform_manager/platform_manager_config.thrift). It runs at boot before any FRU, EEPROM, or firmware access, and can stay running to track hot-plug.

What it does:

Determines the platform and loads its config.
Package management: installs the BSP RPM named in the config (bspKmodsRpmName, bspKmodsRpmVersion) if needed. When the BSP version changed or --reload_kmods=true, it closes open watchdog devices (to avoid a reset), unloads the BSP and shared kernel modules listed in the BSP's /usr/local/<vendor>_bsp/kmods.json in reverse order, runs depmod, and loads nonBspKmodsToLoad.
Exploration: walks the FRU tree described in the config, checks presence, creates I2C and PCI devices (which loads their drivers on demand), and reads IDPROMs.
Device map: creates stable symlinks under /run/devmap/, such as /run/devmap/i2c-busses/OPTICS_1, /run/devmap/sensors/SCM_INLET_TEMP, /run/devmap/eeproms/CHASSIS_EEPROM, /run/devmap/fpgas/IOB_FPGA, /run/devmap/xcvrs/XCVR_1, /run/devmap/leds/PORT_1_LED_1. Other services use these paths instead of raw /dev/i2c-N numbers, which can change between boots.

Run Modes

Mode	Command	Behavior
One-shot (default)	`platform_manager --run_once=true`	Load config, explore, create symlinks, then exit with status 0 on success or 1 on failure
Daemon	`platform_manager --run_once=false`	Same, then start the Thrift service and send the systemd `sd_notify` ready signal

Flags

Flag	Default	Meaning
`--run_once`	`true`	One-shot mode
`--thrift_port`	`5975`	Thrift port in daemon mode
`--explore_interval_s`	`60`	How often the platform is re-explored
`--enable_pkg_mgmnt`	`true`	Download and install the BSP RPM
`--reload_kmods`	`false`	Force a kernel module reload even if the BSP RPM did not change
`--kmod_unload_retries`	`10`	Attempts at the kmod unload pass before giving up
`--kmod_unload_retry_backoff_s`	`3`	Seconds between unload attempts
`--local_rpm_path`		Install this local BSP RPM file instead of resolving one
`--config_file`		Override the embedded config

The Thrift API (platform_manager_service.thrift) answers questions such as the platform name and the BSP version (bspBaseName, bspVersion, kernelVersion); sensor_service and others consume it.

sensor_service

sensor_service reads every sensor listed in sensor_service.json (temperature, voltage, current, power, typically through the /run/devmap/sensors/... paths), applies the configured conversions, and serves the values over Thrift. It is the source of truth for sensor data that other services, notably fan_service, rely on. It also streams stats to FSDB.

Flag	Default	Meaning
`--thrift_port`	`5970`	Thrift port
`--sensor_fetch_interval`	`5`	Seconds between sensor reads
`--fsdb_statsStream_interval_seconds`	`5`	Interval at which FSDB stats subscriptions are served
`--reboot_history_dir`	(from the reboot-cause config)	Directory read for reboot history, served to `fboss2 show reboot-history`
`--config_file`		Override the embedded config

Its README warns that if the platform is unsupported or missing, the service crashes. sensor_service_client queries it from the command line.

fan_service

fan_service performs thermal control for the chassis. Its config (fan_service.json) defines zones: each zone has fans, a set of sensors, and how the zone's PWM is derived from them (maximum, minimum, or average of per-sensor values). Each sensor has a table or formula mapping its reading to a PWM value, and separate tables can apply when the system is healthy or when a module failed. It also detects dead fans and sensors and reacts accordingly.

Flag	Default	Meaning
`--thrift_port`	`5972`	Thrift port
`--control_interval`	`1`	Seconds between checks of sensor readings and PWM programming
`--subscribe_to_qsfp_data_from_fsdb`	`false`	Use optics state and stats from FSDB
`--config_file`		Override the embedded config

Note: The fan_service README says the default control interval is 5 seconds; the code (fan_service/Main.cpp) sets it to 1.

fan_service logs to /var/facebook/log/fan_service.log per its README; the log explains which sensor reading determined each zone's PWM. If it fails at start-up with a port conflict, another instance is running or something else holds port 5972. fboss2 set fanhold holds the fans at a fixed PWM for testing.

data_corral_service

data_corral_service detects FRU presence (fan trays, PSUs, PIMs, and so on) and programs the corresponding presence or status LEDs.

Flag	Default	Meaning
`--thrift_port`	`5971`	Thrift port
`--refresh_interval_ms`	`10000`	How often FRU presence is refreshed and LEDs are programmed

led_service

led_service controls the front-panel port LEDs based on port and transceiver state. It uses the platform mapping and the BSP platform mapping (which defines LED sysfs paths) like qsfp_service, and reads /etc/coop/led.conf (--led_config). Per-platform default led.conf files are in fboss/oss/scripts/run_configs/default_configs/<platform>/.

Flag	Default	Meaning
`--led_service_port`	`5930`	Thrift port
`--led_config`	`/etc/coop/led.conf`	Config file

It is built by the led_targets CMake target together with led_service_hw_test, which run_test.py led runs.

Testing the Platform Stack

./bin/run_test.py platform runs the platform hardware test binaries: platform_hw_test, data_corral_service_hw_test, fan_service_hw_test, fw_util_hw_test, sensor_service_hw_test, weutil_hw_test, and platform_manager_hw_test. Use --type <binary> to run just one. All of them belong to the T0 tier. BSP kernel modules have their own suite (bsp_tests, configured by bsp_tests.json). See Test Suites.