Re: [PATCH RFC 03/20] ctlv: Add the root family specification and generated files

[Jiri Pirko]

Tue, Oct 20, 2026 at 02:55:20PM +0200, jgg@xxxxxxxx wrote:
>On Tue, Oct 20, 2026 at 02:28:55PM +0200, Jiri Pirko wrote:
>> Tue, Oct 20, 2026 at 01:29:45AM +0200, jgg@xxxxxxxxxx wrote:
>> >> [ ... 238 lines skipped ... ]
>> >> --- /dev/null
>> >> +++ b/Documentation/ctlv/families.yaml
>> >> @@ -0,0 +1,13 @@
>> >> +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
>> >> +%YAML 1.2
>> >> +---
>> >> +# Append-only registry of CTLV family names, indexed by family ID: the entry at
>> >> +# index N has family ID N, up to 65535. The root family owns ID 0 and heads the
>> >> +# list, and every other entry comes after the entry of the family it inherits.
>> >> +# An entry may be marked deprecated, but never reordered, removed, renamed or
>> >> +# reused, its position being its wire identity. Every entry must have a
>> >> +# specification in specs/<name>.yaml, and is added by the change that adds the
>> >> +# implementation. Fixtures under tools/ctlv/tests/ are not registered.
>> >> +
>> >> +families:
>> >> +  - ctlv
>> >
>> >I see where you are coming from with this, but it is going to be
>> >problematic from a global kernel perspective. Given CTLV is imagined
>> >as a general tool for any subsystem we cannot control the tree that
>> >things merge through. It will not be like netdev where there is one
>> >authoritative tree with a linear history.
>> >
>> >So if Bob and Jane maintainers both add their own subsystems by the
>> >time it gets to Linus the IDs will get scrambled, and bisection will
>> >be lost. 
>> >
>> >Either changes to this file must be strictly done in a single tree
>> >with shared branches (which is going to be a bit hard process wise)
>> >
>> >Or we need to put the ID #s here and have some simple process to
>> >coordinate them during the development process. Since new families are
>> >probably rare it shouldn't be a big deal
>> 
>> Exactly. Collision is not very likely. Explicit ID or implicit, scramble
>> would still happen. And in that case it is resolvable.
>
>I think because of process if it is kept like this we will have to
>merge 'dead code' to reserve spots for people doing new work..
>
>But at a minimum this comment above needs a big fat warning not to
>change this file without consulting with XYZ to coordinate merging.

Agreed.