Few more fixes by Claude#1188
Conversation
BD_SWAP_TECH_MODE_SET_UUID had the same value (1 << 3) as BD_SWAP_TECH_MODE_SET_LABEL making it impossible to distinguish between label and UUID capability checks. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The region filter was comparing bus_name against the region device name instead of region_name, so filtering by region never worked. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The test for setting UUID on MSDOS partition table was calling part_set_part_name instead of part_set_part_uuid. The test passed because MSDOS doesn't support partition names either, but it wasn't actually testing UUID functionality. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthroughThe PR makes three distinct changes: (1) Updates the bitmask value for Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/plugins/swap.h`:
- Around line 29-30: The enum renumbering changed public ABI: restore the
original bit values for BD_SWAP_TECH_MODE_SET_LABEL and
BD_SWAP_TECH_MODE_SET_UUID in swap.h so existing binaries continue to pass the
same integer flags to bd_swap_is_tech_avail(); do not change assigned bit-shifts
for BDSwapTechMode values, or if you must change them, add a compatibility layer
that accepts the old bit values and maps them to the new ones and update the
SONAME/soversion (and document the incompatibility in release notes) so callers
are not silently misinterpreted.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 022bdc7b-82f4-432f-bf02-17736c7fa18d
📒 Files selected for processing (4)
src/lib/plugin_apis/swap.apisrc/plugins/nvdimm.csrc/plugins/swap.htests/part_test.py
| BD_SWAP_TECH_MODE_SET_LABEL = 1 << 3, | ||
| BD_SWAP_TECH_MODE_SET_UUID = 1 << 3, | ||
| BD_SWAP_TECH_MODE_SET_UUID = 1 << 4, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== References to the public flag and ABI boundary =="
rg -n -C2 '\b(BDSwapTechMode|BD_SWAP_TECH_MODE_SET_UUID|bd_swap_is_tech_avail\s*\()' .
echo
echo "== Build/install/versioning metadata =="
rg -n -C2 'swap\.h|swap\.api|install_headers|gnome\.generate_gir|soversion|version-info|LT_VERSION|current:revision:age' \
-g 'meson.build' -g 'configure.ac' -g 'Makefile.am' -g '*.pc.in' -g '*.map' -g '*.symbols' -g '*.gir' .Repository: storaged-project/libblockdev
Length of output: 15170
This enum renumbering breaks the public ABI.
swap.h is installed as public API (Makefile.am:175), and BDSwapTechMode values are compiled directly into client binaries. Renumbering BD_SWAP_TECH_MODE_SET_UUID from 1 << 3 to 1 << 4 means old clients will pass 1 << 3 to bd_swap_is_tech_avail(), which the updated library now silently interprets as BD_SWAP_TECH_MODE_SET_LABEL. This corrupts the operation without error. Pair this with a soversion bump (currently -version-info 3:0:0) and/or a compatibility release note.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/plugins/swap.h` around lines 29 - 30, The enum renumbering changed public
ABI: restore the original bit values for BD_SWAP_TECH_MODE_SET_LABEL and
BD_SWAP_TECH_MODE_SET_UUID in swap.h so existing binaries continue to pass the
same integer flags to bd_swap_is_tech_avail(); do not change assigned bit-shifts
for BDSwapTechMode values, or if you must change them, add a compatibility layer
that accepts the old bit values and maps them to the new ones and update the
SONAME/soversion (and document the incompatibility in release notes) so callers
are not silently misinterpreted.
Looks like we might have finally fixed all (or at least most of) the issues
Summary by CodeRabbit
Bug Fixes
Chores