netdev - Re: [RFC net-next 2/4] ynl: add the schema for the schemas

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL_JsqJTg58HGJG6QbdNmHuUVK8EoEtzbQkMQOiprw01ryv83g@mail.gmail.com>
Date:   Wed, 28 Sep 2022 07:32:16 -0500
From:   Rob Herring <robh@...nel.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
        pabeni@...hat.com, sdf@...gle.com, jacob.e.keller@...el.com,
        vadfed@...com, johannes@...solutions.net, jiri@...nulli.us,
        dsahern@...nel.org, stephen@...workplumber.org, fw@...len.de,
        linux-doc@...r.kernel.org
Subject: Re: [RFC net-next 2/4] ynl: add the schema for the schemas

On Tue, Sep 27, 2022 at 4:56 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Mon, 26 Sep 2022 11:10:56 -0500 Rob Herring wrote:
> > On Wed, Aug 10, 2022 at 07:23:02PM -0700, Jakub Kicinski wrote:
> > > A schema in jsonschema format which should be familiar
> > > to dt-bindings writers. It looks kinda hard to read, TBH,
> > > I'm not sure how to make it better.

[...]

> > > +    description: Description of the family
> > > +    type: string
> > > +  version:
> > > +    description: Version of the family as defined by genetlink.
> > > +    type: integer
> >
> > Do you have the need to define the int size? We did our own keyword for
> > this, but since then I've looked at several other projects that have
> > used something like 'format: uint32'. There was some chatter about
> > trying to standardize this, but I haven't checked in a while.
>
> It's 8 bits in theory (struct genlmsghdr::version), in practice it's
> never used, and pretty much ignored. The jsonschema I have on Fedora
> does not know about uint8.

It wouldn't. It's some users of jsonschema that have added their own
thing. With python-jsonschema, you can add your own FormatChecker
class to handle custom 'format' entries.


> > > +  attr-cnt-suffix:
> > > +    description: Suffix for last member of attribute enum, default is "MAX".
> > > +    type: string
> > > +  headers:
> > > +    description: C headers defining the protocol
> > > +    type: object
> > > +    additionalProperties: False
> > > +    properties:
> > > +      uapi:
> > > +        description: Path under include/uapi where protocol definition is placed
> > > +        type: string
> > > +      kernel:
> > > +        description: Additional headers on which the protocol definition depends (kernel side)
> > > +        anyOf: &str-or-arrstr
> > > +          -
> > > +            type: array
> > > +            items:
> > > +              type: string
> > > +          -
> > > +            type: string
> > > +      user:
> > > +        description: Additional headers on which the protocol definition depends (user side)
> > > +        anyOf: *str-or-arrstr
> >
> > For DT, we stick to a JSON compatible subset of YAML, so no anchors. The
> > jsonschema way to do this is using '$defs' (or 'definitions' before the
> > spec standardized it) and '$ref'.
>
> I need to read up on this. Is it possible to extend a type?
> We really need a way to define a narrow set of properties for "going
> forward" while the old families have extra quirks. I couldn't find any
> jsonschema docs on how the inherit and extend.

You can add constraints, but you can't override what you inherit.

You do that with a $ref (and unevaluatedProperties if adding
properties) to the base schema and then add more schema constraints.
For example, we define something as an array with a $ref and then add
the bounds to it. That can also be done by 2 schemas applied
independently. However, if it's constraining properties present in an
object, then that can't be independent (that's where
unevaluatedProperties comes into play).

Rob