Assign PIDs in aligned blocks of 16 - #4
Merged
Merged
Conversation
mrpollo
marked this pull request as ready for review
August 27, 2026 16:18
Vendors were taking sequential single PIDs (0x0001, 0x0002, 0x0003), interleaving unrelated manufacturers across the low range. The allocation unit is now an aligned block of 16, 0xNNN0-0xNNNF, claimed in a new per-manufacturer `blocks` list; every PID a vendor is assigned has to fall inside one of their blocks. Existing assignments do not move. PX4, ZeroOne and NewBeeDrone simply declare the block that already contains their PID. Syro's 0x0001 and Agam's 0x0002 and 0x0003 sit in the interleaved low range where no clean block exists, so they carry a new `legacy: true` flag: exempt from containment, frozen in place, still globally unique. No manufacturer may claim a block holding another vendor's PID, which permanently freezes 0x0000-0x000F. `legacy` is maintainer-set only. It is valid solely for the PIDs named in LEGACY_PIDS, and only on entries dated before 2026-09-01, so a request cannot grant itself the exemption without editing this validator. Both fields are additive, so deployed PX4-Autopilot checkers that fetch usb-ids.yaml from main keep working unchanged.
The README, the PR checklist and the issue form all still told requesters to pick the lowest free PID. They now describe claiming an aligned 16-PID block, with a reminder that PID values are hexadecimal: after "0x0039" comes "0x003A", not "0x0040". The sequential-single habit came partly from reading the list as decimal. CODEOWNERS puts the registry and its validator under maintainer review. It stays advisory until main has branch protection with "Require review from Code Owners" enabled.
mrpollo
force-pushed
the
block-allocation-policy
branch
from
August 27, 2026 16:21
6f7bc28 to
f27c802
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces the "pick the lowest free PID" policy with per-manufacturer block allocation. The allocation unit is now an aligned block of 16 PIDs,
0xNNN0-0xNNNF, claimed in a newblockslist on each manufacturer. Every PID a vendor is assigned has to fall inside one of their blocks.Blocks are nibble-aligned so a vendor's entire product line matches a single glob:
003?in a udev rule,3643:003in a log grep, one row in a table instead of five entries scattered across the range. There are 4,096 blocks under0x3643and five manufacturers registered so far, so the space cannot realistically exhaust. The sequential-single habit was costing us that property, not address space. Claim a block when you have hardware to name, and another one when the first fills up; no speculative reservations.Nothing moves. No
pid,boardordatevalue changes anywhere in this diff, because those are burned into hardware that is already shipping. Both new fields are additive, which matters because PX4-Autopilot CI, including release branches carrying older copies ofcheck_usb_ids.py, fetchesusb-ids.yamlfrommainat check time. Older checkers ignoreblocksandlegacyand keep working exactly as before.0x001D0x0010-0x001F, which already contained it0x15E00x15E0-0x15EF, which already contained it0x00500x0050-0x005F, which already contained it0x0001legacy: true, frozen, no block0x0002,0x0003legacy: true, frozen, no blockThree of the five already sat inside a clean block and simply declare it. Syro and Agam are in the interleaved low range where no clean block exists, so they are grandfathered with
legacy: true: exempt from block containment, frozen in place, still globally unique. Since no manufacturer may claim a block holding another vendor's PID,0x0000-0x000Fis now permanently unclaimable, which is the right outcome for a range holding three assignments split across two unrelated companies.