Almost everywhere OpenBMC runs, it is a server BMC stack, acting as sidecar to a much bigger host CPU, and it carries assumptions one can't see by reading the code. The only way to find assumptions buried that deep is to take the stack somewhere it was never meant to go, so we ran it on a high-radix fabric switch, then on a chassis of eighteen BMCs, and watched what broke. Our fabric switch has no separate control-plane processor, so the BMC is the switch's main processor.

Because there is no host CPU underneath, the BMC drives the fabric hardware itself. A daemon reads the switch ASIC's port counters directly, and through the module-management layer the BMC talks to every cable in the switch to read presence, temperature, identity, and more. All of that gets republished on D-Bus and projected into the DMTF Fabrics / Switches / Ports resource tree. We'll show where a standard built for servers bends to fit a fabric, and the one or two places where we decided an empty field was more honest than a server's answer.

We then put a switch into a chassis with multiple individually managed line cards, and that is where it gets interesting. Upstream bmcweb's Redfish aggregation is built for a single satellite and on our quest to aggregate multiple satellites, we discover how challenging lifting a seemingly simple assumption can be. We walk through each change as a concrete gap with a concrete fix, able to handle the single-server case the code was built for and our chassis paradigm.