fix: discover DEV_DAX devices whose sysfs path has no region component

[seohui-XCENA]

🤔 Background & Motivation (Why)

The resource manager finds no pool on a machine whose DAX device sits under a platform hmem device, even though the device is present and healthy (daxctl reports mode: devdax, /dev/dax0.0 exists, the UUID header is written):

$ maru-resource-manager --state-dir $(mktemp -d)
no CXL/DAX devices found — starting with empty pool
ready — listening on 0.0.0.0:9850
pools empty, rescanning for CXL/DAX devices...      (every 10s, forever)

With no pool there is nothing to allocate from, so maru-server and MaruHandler cannot do anything either — Maru is unusable on such a machine, single node included.

scanDevices() derived the dax_region index by searching the sysfs symlink target for region<N>. That works for pmem (.../ndbus0/region0/dax_region0/dax0.0) and for a CXL region, but an hmem-backed device has no region component in its path:

$ readlink /sys/bus/dax/devices/dax0.0
../../../devices/platform/hmem.0/dax0.0

so the lookup failed and the device was skipped with no log line — which is why the only visible symptom was "no devices found".

🏗️ Design Changes

• The dax_region index now comes from the device name, with the old link-target parse kept as a fallback. This removes a path dependency rather than adding one: the old code needed the sysfs hierarchy to spell region<N>, and that hierarchy differs per provider and per platform. The name does not — alloc_dax_region and devm_create_dev_dax are built into the kernel core rather than into any module, and dax_pmem, dax_cxl and dax_hmem all call into them, so dax<dax_region id>.<dev_dax id> is produced by one shared code path for every provider. Keeping the old parse as a fallback also means the set of discovered devices is a superset of what it was before, so a working setup cannot regress.
• How the device path itself is found is untouched — it never went through the symlink.
• Devices skipped during discovery are now logged with the reason.
• New internal function parseRegionIndexFromDaxName(), declared in pool_manager.h so tests can link it.
• No change to pool id numbering, the on-disk metadata format, the WAL format, or the wire protocol.

📝 Implementation Details

Only the region-id derivation changes. How the device path is found is untouched — it never went through the symlink:

	Before	After
device path	/dev/ + entry name from readdir("/sys/bus/dax/devices")	unchanged
region id	first region<N> found anywhere in the sysfs link target	first number in the device name; link target only as fallback

Before:  getRegionIndexForDax("dax0.0")
           readlink("/sys/bus/dax/devices/dax0.0") -> ".../platform/hmem.0/dax0.0"
             target.find("region") -> npos  ->  skipped, silently

After:   getRegionIndexForDax("dax0.0")
           parseRegionIndexFromDaxName("dax0.0") -> 0      <- readlink not reached
           (link-target parse runs only if the name does not parse)

Pool ids are unchanged

Worth a reviewer's eye, since poolId is a persistence key — it names pool_<id>.meta (metadata.cpp:33), is rejected on mismatch when loading (metadata.cpp:54), and is what WAL replay resolves a pool by (wal.cpp:125-127). A renumbering would orphan existing state.

It does not happen here. Wherever discovery already worked, both sources yield the same number: dax_region->id equals the nd_region id for pmem and the CXL region id for CXL, and that is precisely the region<N> in the path. Where discovery failed there was no pool and no metadata to be compatible with.

✅ Tests

• Unit tests
• Integration tests
• Manual tests
• No tests needed (reason: )

Unit — 3 new gtest cases in tests/test_dax_region_index.cpp; ctest 19/19, clean under -Wall -Wextra -Wpedantic.

Case	Covers
ParsesRegionIndexFromDeviceName	dax0.0, dax0.1, dax3.7, dax12.0
RejectsMalformedNames	dax, dax0, dax0., dax.0, daxfoo, dax_region, pmem0, ""
ResolvesHmemDeviceWhoseLinkTargetHasNoRegion	asserts the hmem link target has no region component, and that the name still resolves — the regression

Manual, on an hmem-backed devdax device: the rescan loop is gone and the pool registers at startup. STATS_REQ reports the pool, and ALLOC_REQ → mmap → write → FREE_REQ completes. The full stack (resource manager + maru-server + two MaruHandler clients storing and retrieving over several rounds) runs green, with the two clients receiving disjoint ranges.

Not covered: no pmem or CXL-region machine was available, so the claim that those topologies are unaffected rests on the two arguments above rather than on a run. On such a machine it can be checked in a minute — for every device the first number of the name should equal dax_region/id, and pool_<id>.meta should keep its existing filename.

🔗 Related Issues (optional)

📦 Release Note (for auto-generation / write in English)

NEW

CHANGED

• Resource Manager: skipped DAX devices are now logged with the reason instead of being passed over silently.

FIXED

• Resource Manager: DEV_DAX devices whose sysfs path carries no region<N> component (e.g. a dax_region on a platform hmem device) were skipped during discovery, leaving the daemon with no pools and no way to allocate.

IMPORTANT NOTES

[github-actions]

Coverage Report

File	Stmts	Miss	Cover	Missing
__init__.py	6	0	100%
__main__.py	3	3	0%	5, 7–8
allocation_manager.py	129	11	91%	30–31, 44–45, 52, 237–238, 268–271
client.py	187	8	96%	88, 130, 147–148, 311–313, 319
config.py	46	1	98%	72
constants.py	9	0	100%
device_scanner.py	115	5	96%	13–15, 63, 96
handler.py	557	86	85%	153, 168, 179–186, 194–196, 211, 217–219, 227, 238–243, 248, 273, 300–301, 305, 345, 349–350, 355, 377, 384–385, 389–395, 398, 402–404, 420, 422–423, 432, 486, 507, 517–518, 624–626, 633, 755–758, 761, 772–775, 781, 867, 971, 1134–1138, 1144, 1155–1159, 1165, 1244, 1249, 1291
ipc.py	275	2	99%	365, 441
kv_manager.py	108	0	100%
logging_setup.py	19	0	100%
plugin.py	59	3	95%	65–67
protocol.py	233	0	100%
resource_manager_installer.py	103	13	87%	80–86, 167, 169–172, 187
rpc_async_client.py	190	0	100%
rpc_async_server.py	111	0	100%
rpc_client.py	71	0	100%
rpc_client_base.py	106	10	91%	185, 221–222, 233–234, 306–307, 311–312, 375
rpc_handler_mixin.py	106	19	82%	154–156, 159–161, 219–222, 227, 231–235, 256–257, 263
rpc_server.py	64	0	100%
serializer.py	81	0	100%
server.py	170	13	92%	64–65, 73, 168, 172, 243, 247, 265–266, 357–359, 444
stats_manager.py	95	0	100%
types.py	60	1	98%	145
uds_helpers.py	13	0	100%
memory
__init__.py	5	0	100%
allocator.py	55	0	100%
mapper.py	164	17	90%	65–74, 77–80, 293, 342, 376
owned_region_manager.py	101	1	99%	212
types.py	63	0	100%
TOTAL	3325	193	94%

Tests	Skipped	Failures	Errors	Time
724	4 💤	0 ❌	0 🔥	5.927s ⏱️