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

[Jason Gunthorpe]

> [ ... 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

-- 
Jason