Linux Documentation
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>
Cc: linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-api@vger.kernel.org, x86@kernel.org, kvm@vger.kernel.org,
	linux-doc@vger.kernel.org, jgg@ziepe.ca, david.quigley@intel.com,
	lukas@wunner.de, ksinyuk@kernel.org, rodrigo.vivi@intel.com,
	cedric.xing@intel.com, sameo@meta.com, drdeeglaze@gmail.com,
	James.Bottomley@HansenPartnership.com, aik@amd.com,
	jpiotrowski@nvidia.com, qinkun@google.com, pgonda@google.com,
	alistair.francis@wdc.com, ankita@nvidia.com,
	suzuki.poulose@arm.com, kas@kernel.org,
	rick.p.edgecombe@intel.com, elena.reshetova@intel.com,
	dave.hansen@linux.intel.com,
	sathyanarayanan.kuppuswamy@linux.intel.com, peter.fang@intel.com
Subject: Re: [PATCH RFC 01/20] ctlv: Add the schema language and generator
Date: Tue, 20 Oct 2026 23:31:32 +0100	[thread overview]
Message-ID: <20261020233132.793b7e97@jic23-hlaptop> (raw)
In-Reply-To: <20261015145053.3664509-2-jiri@resnulli.us>

On Thu, 15 Oct 2026 16:50:34 +0200
Jiri Pirko <jiri@resnulli.us> wrote:

> From: Jiri Pirko <jiri@nvidia.com>
> 
> Define the YAML schema and append-only family registry. Add ctlvgen to
> validate specifications and emit kernel and UAPI outputs.
> 
> Assisted-by: Cursor: GPT-5.6 Sol
> Assisted-by: Cursor: Claude Opus 5.5
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>

Obviously you asked for broad structural review and this isn't that. I'm terrible
at reading code for just the big picture but feel free to ignore the small stuff
in this reply.

My python being even worse than my yaml I'll only say that
part looked plausible to me!

> diff --git a/Documentation/ctlv/ctlv-schema.yaml b/Documentation/ctlv/ctlv-schema.yaml
> new file mode 100644
> index 000000000000..38fd56e6627c
> --- /dev/null
> +++ b/Documentation/ctlv/ctlv-schema.yaml
> @@ -0,0 +1,359 @@
> +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
> +%YAML 1.2
> +---
> +$id: http://kernel.org/schemas/ctlv/ctlv-schema.yaml#
> +$schema: https://json-schema.org/draft-07/schema
> +
> +# The syntax gate for a CTLV family specification: permitted keys, their shapes
> +# and the closed sets of keywords. Anything needing more than one declaration at
> +# a time is checked by tools/ctlv/ctlvgen/lib/semantics.py.
> +
> +$defs:
> +  name:
> +    description: Kebab-case identifier. A dot is reserved for selectors.
> +    type: string
> +    pattern: ^[a-z0-9]+(-[a-z0-9]+)*$
> +
> +  family-name:
> +    description: Name carried by family discovery.
> +    allOf:
> +      - $ref: '#/$defs/name'
> +      - maxLength: 63
> +
> +  selector:
> +    description: |

Really trivial but nice to drop | where it doesn't make sense to
force line break preservation like here. 

> +      A named attr set, a whole attr group, or one exact attr as
> +      "group.attr". There are no tuple selectors and no cross-family
> +      qualification.
> +    type: string
> +    pattern: ^[a-z0-9]+(-[a-z0-9]+)*(\.[a-z0-9]+(-[a-z0-9]+)*)?$
> +
> +  selectors:
> +    oneOf:
> +      - $ref: '#/$defs/selector'
> +      - type: array
> +        minItems: 1
> +        items:
> +          $ref: '#/$defs/selector'

My yaml is terrible (and all learnt form reviewing DT bindings which are
undoubtedly perfect :) but random LLM agrees with me that you can simplify
this as it's a local definition.  I think doing so makes life a little
easier for reader by indicating it is thing defined a few lines up.

            $ref: 'selector'

I don't care that much though.

> +
> +  uint:
> +    type: integer
> +    minimum: 0
> +    maximum: 4294967295
> +
> +  integer-bound:
> +    type: integer
> +    minimum: -9223372036854775808
> +    maximum: 18446744073709551615
> +
> +  max-occurrences:
> +    description: |
> +      A finite positive count, or unlimited, which is reachable only from
> +      query replies.
> +    oneOf:
> +      - type: integer
> +        minimum: 1
> +        maximum: 4294967295
> +      - const: unlimited
> +
> +  unit:
> +    description: CTLV-owned unit, matching enum ctlv_unit.
> +    enum: [ seconds, hertz, bytes, celsius ]

These are used in here?  I'm sure some are but guessing not
all of them yet.


> +  attr:
> +    description: |
> +      One attr declaration. Exactly one primary form out of type, enum,
> +      flags, attrs and blob must be present. optional-attrs and recursive
> +      may only accompany attrs.

Maybe worth the yaml gynastics needed to enforce this rather than
just putting it in the description?  An LLM fed me something when
I sanity checked how bad it would be and it's only somewhat nasty...

Bunch of:
 oneOf:
      - required: [ type ]
        not: { anyOf: [ { required: [ enum ] }, { required: [ flags ] }, { required: [ attrs ] }, 	{ required: [ blob ] } ] }

lines, though I thought there was a more compact way to do it.


> +    type: object
> +    required: [ name ]
> +    additionalProperties: false
> +    properties:
> +      name:
> +        $ref: '#/$defs/name'
> +      type:
> +        description: |
> +          Primitive payload. Integers are always 64-bit, and a bool is one
> +          byte holding zero or one.
> +        enum: [ uint, sint, bool, string, binary ]
> +      enum:
> +        description: Name of an enum definition; implies an unsigned payload.
> +        $ref: '#/$defs/name'
> +      flags:
> +        description: Name of a flags definition; implies an unsigned payload.
> +        $ref: '#/$defs/name'
> +      attrs:
> +        description: Nested payload, given as selectors.
> +        $ref: '#/$defs/selectors'
> +      optional-attrs:
> +        description: Further nested payload whose placements are optional.
> +        $ref: '#/$defs/selectors'
> +      recursive:
> +        description: |
> +          The nested payload is one attr set that may contain this attr
> +          again, describing a structure of any depth. Only a query reply can
> +          hold one, since such a nest has no maximum length.
> +        const: true
> +      blob:
> +        $ref: '#/$defs/blob'
> +      min:
> +        description: Inclusive minimum of an integer payload.
> +        $ref: '#/$defs/integer-bound'
> +      max:
> +        description: Inclusive maximum of an integer payload.
> +        $ref: '#/$defs/integer-bound'
> +      length:
> +        description: Exact payload length of a binary attr.
> +        $ref: '#/$defs/uint'
> +      min-length:
> +        description: |
> +          Minimum payload length, excluding the terminator of a string.
> +        $ref: '#/$defs/uint'
> +      max-length:
> +        description: |
> +          Maximum payload length, excluding the terminator of a string.
> +        $ref: '#/$defs/uint'
> +      unit:
> +        $ref: '#/$defs/unit'
> +      scale:
> +        description: Decimal exponent applied to the payload.
> +        type: integer
> +        minimum: -128
> +        maximum: 127
> +      max-occurrences:
> +        $ref: '#/$defs/max-occurrences'
> +

  reply	other threads:[~2026-10-20 22:31 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 14:50 [PATCH RFC 00/20] attestation: Add a common subsystem and TDX support Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 01/20] ctlv: Add the schema language and generator Jiri Pirko
2026-10-20 22:31   ` Jonathan Cameron [this message]
2026-10-21 13:23     ` Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 02/20] ctlv: Add the UAPI wire format and family API Jiri Pirko
2026-10-19 23:29   ` Jason Gunthorpe
2026-10-20 12:26     ` Jiri Pirko
2026-10-20 23:00   ` Jonathan Cameron
2026-10-20 23:39     ` Jonathan Cameron
2026-10-15 14:50 ` [PATCH RFC 03/20] ctlv: Add the root family specification and generated files Jiri Pirko
2026-10-19 23:29   ` Jason Gunthorpe
2026-10-20 12:28     ` Jiri Pirko
2026-10-20 12:55       ` Jason Gunthorpe
2026-10-20 14:07         ` Jiri Pirko
2026-10-20 23:30   ` Jonathan Cameron
2026-10-15 14:50 ` [PATCH RFC 04/20] Documentation: ctlv: Add userspace ABI Jiri Pirko
2026-10-19 23:29   ` Jason Gunthorpe
2026-10-20 14:06     ` Jiri Pirko
2026-10-21  0:11   ` Jonathan Cameron
2026-10-15 14:50 ` [PATCH RFC 05/20] ctlv: Prepare message input handling Jiri Pirko
2026-10-21  0:43   ` Jonathan Cameron
2026-10-15 14:50 ` [PATCH RFC 06/20] ctlv: Prepare blob descriptor validation Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 07/20] ctlv: Prepare schema validation Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 08/20] ctlv: Prepare message output handling Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 09/20] ctlv: Prepare VA blob handling Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 10/20] ctlv: Prepare event queue support Jiri Pirko
2026-10-21  1:12   ` Jonathan Cameron
2026-10-15 14:50 ` [PATCH RFC 11/20] ctlv: Prepare runtime introspection Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 12/20] ctlv: Add device and operation dispatch Jiri Pirko
2026-10-21  1:25   ` Jonathan Cameron
2026-10-15 14:50 ` [PATCH RFC 13/20] Documentation: ctlv: Describe how to write a family Jiri Pirko
2026-10-19 23:29   ` Jason Gunthorpe
2026-10-15 14:50 ` [PATCH RFC 14/20] attestation: Add the base family specification and generated files Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 15/20] attestation: Prepare provider and instance core Jiri Pirko
2026-10-19 23:29   ` Jason Gunthorpe
2026-10-21 13:04     ` Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 16/20] attestation: Prepare measurement register journal Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 17/20] attestation: Add CTLV operation handling Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 18/20] tdx-guest: Expose the native attestation service API Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 19/20] attestation: Add the TDX family specification and generated files Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 20/20] attestation: Add the TDX family implementation Jiri Pirko
2026-10-16 23:43 ` [PATCH RFC 00/20] attestation: Add a common subsystem and TDX support Jason Gunthorpe
2026-10-17 18:16   ` Dionna Glaze
2026-10-17 19:06     ` Jarkko Sakkinen
2026-10-17 19:08       ` Jarkko Sakkinen
2026-10-17 19:22         ` Jarkko Sakkinen
2026-10-17 20:55       ` Jason Gunthorpe
2026-10-17 21:14         ` Jarkko Sakkinen
2026-10-17 20:34     ` Jason Gunthorpe
2026-10-17 20:55       ` Jarkko Sakkinen
2026-10-17 23:10         ` Jason Gunthorpe
2026-10-18 23:53           ` Dionna Glaze
2026-10-19 12:08             ` Jiri Pirko
2026-10-19 16:10               ` Dionna Glaze
2026-10-19 22:56                 ` Jason Gunthorpe
2026-10-21  8:33                   ` Jiri Pirko
2026-10-20  9:26                 ` Jiri Pirko
2026-10-20 13:45                 ` Mimi Zohar
2026-10-20 14:06                   ` Jason Gunthorpe
2026-10-20 15:22                     ` Mimi Zohar
2026-10-20 16:11                       ` Yeoreum Yun
2026-10-20 16:52                         ` Jason Gunthorpe
2026-10-21 12:23                           ` Mimi Zohar
2026-10-21 13:18                             ` Jarkko Sakkinen
2026-10-21 12:48                         ` James Bottomley
2026-10-19 12:40             ` Jarkko Sakkinen
2026-10-19 23:11             ` Jason Gunthorpe
2026-10-20 12:49       ` James Bottomley
2026-10-20 13:13         ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261020233132.793b7e97@jic23-hlaptop \
    --to=jic23@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=aik@amd.com \
    --cc=alistair.francis@wdc.com \
    --cc=ankita@nvidia.com \
    --cc=cedric.xing@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david.quigley@intel.com \
    --cc=drdeeglaze@gmail.com \
    --cc=elena.reshetova@intel.com \
    --cc=jgg@ziepe.ca \
    --cc=jiri@resnulli.us \
    --cc=jpiotrowski@nvidia.com \
    --cc=kas@kernel.org \
    --cc=ksinyuk@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=peter.fang@intel.com \
    --cc=pgonda@google.com \
    --cc=qinkun@google.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=sameo@meta.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=suzuki.poulose@arm.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox