From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751595AbdJVTOR (ORCPT ); Sun, 22 Oct 2017 15:14:17 -0400 Received: from mail-pf0-f173.google.com ([209.85.192.173]:56427 "EHLO mail-pf0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751422AbdJVTOO (ORCPT ); Sun, 22 Oct 2017 15:14:14 -0400 X-Google-Smtp-Source: ABhQp+TyhB8Y6paWFK1DFU4LLW5TkwKLmB0Tur6KeBCpLVRpFOG8BUdILA03ATFsqC0rqCr+pjTL6a3+ALQxM/M5+m8= MIME-Version: 1.0 In-Reply-To: <744E94DE-E4AE-425B-9B02-E0E022017450@konsulko.com> References: <1506628736.28192.9.camel@hp800z> <744E94DE-E4AE-425B-9B02-E0E022017450@konsulko.com> From: Grant Likely Date: Sun, 22 Oct 2017 20:13:53 +0100 X-Google-Sender-Auth: vXR6YLcZ8Vyv8fWmALFE_Ken5OI Message-ID: Subject: Re: [RFC] yamldt v0.5, now a DTS compiler too To: Pantelis Antoniou Cc: David Gibson , Devicetree Compiler , Frank Rowand , Franklin S Cooper Jr , Geert Uytterhoeven , Linux Kernel Mailing List , Marek Vasut , Matt Porter , Phil Elwell , Rob Herring , Simon Glass , Tom Rini , "devicetree@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v9MJEMiY004494 On Sun, Oct 22, 2017 at 7:23 PM, Pantelis Antoniou wrote: > Hi Grant, > >> On Oct 22, 2017, at 19:54 , Grant Likely wrote: >> >> On Fri, Oct 20, 2017 at 8:16 PM, Pantelis Antoniou >> wrote: >>> Hi Grant, >>> >>>> On Oct 20, 2017, at 20:46 , Grant Likely wrote: >>>> >>>> On Thu, Sep 28, 2017 at 8:58 PM, Pantelis Antoniou >>>> wrote: [...] >>> Yes. This is expected. I don’t think pure YAML form is a good match for all >>> the crazy things that are possible (and actually used in practice) with DTS. >> >> I don’t think it is as dire as that. The DTS structure is not complex >> and I think can easily be mapped into pure YAML. But, it does require >> treating the DTS structure separately from its semantic meaning. For >> example, the grammar of nodes, properties and labels easily maps to >> pure YAML, but phandles and overlay trees have semantic meaning that >> must be resolved by DT specific code. I’ll respond to you’re specific >> examples below… >> > > We are in complete agreement here. Single nodes and properties map to YAML perfectly. > It’s the complex way that we build the complete DTB that stress the YAML structures. Okay, good. >>> If we were to force YAML/DT file to be regular YAML files parseable by everything >>> we’d have to rethink a lot of conventions that DT files currently use and I’m afraid >>> a machine translation from DTS to YAML might not be feasible then. >>> >>> OTOH moving to that model might make it possible to use YAML constructs that are not >>> mapped at all to DTS. For instance >>> >>> - foo: true >>> bar: “string” >>> >>> - foo: false >>> bar: “another-string” >>> >>> is not possible to be mapped to a DT node/property structure right now. >> >> I’m not following. Are you saying DT has no way to encode a list of >> nodes? What use case are you imagining? >> > > This threw me off too at first. > > The problem is when you try to convert this into a live tree structure. > > The YAML encoding is > > +SEQ > +MAP > =VAL :foo > =VAL :true > =VAL :bar > =VAL "string > -MAP > +MAP > =VAL :foo > =VAL :false > =VAL :bar > =VAL "another-string > -MAP > -SEQ > > So it’s a sequence of MAPs. > > In a live tree DTS form would be > > noname-property = { foo=true; bar = “string”; }, { foo = false; bar=“another-string”; }; > > We don’t have the capability as right now to express something like this. > > Namely properties containing nodes, and the root of the live tree not being a node. Ah, so you're proposing property data that encodes key/value pairs, correct? Effectively adding another layer of namespace under a property, but that namespace is invisible to and generic DT parsing code in an OS (for how DT is defined today). I would straight out make that structure illegal in the YAML DT metaschema until such time as the semantics are defined. For now properties should only be allowed to contain scalars, or lists of scalars/lists which can be nested. [...] >>>> The encoding differentiates between nodes and properties implicitly >>>> base on whether the contents are a map, or a scalar/list. This does >>>> mean any parser needs to do a bit more work and it may impact what can >>>> be done with validation (I'm not going to talk about validation in >>>> this email though. We'll talk next week.) >>> >>> Hmm, I’m not sure I follow this. Is that related to the metadata problem. >> >> It has to do with iterating over properties or nodes. Nodes and props >> are mixed together, and any code processing them has to explicitly >> check the type to differentiate between the two. The alternative would >> be to collect all properties under a single key: >> >> parent: >> $props: >> foo: hello >> bar: world >> child1: {} >> child2: {} >> > > That’s no problem. It does look weird though. I am using the same parser > for parsing bindings and this might make the files a little bit weird. That it does. I don’t feel strongly about either approach, but I want to see how the different encodings affect doing the schema bits. > > Keep in mind that we have two YAML formats to parse; the hardware description > and the bindings describing them. Three! Hw description, schema & metaschema. :-) But metaschema should be a normal jsonschema file. > >>> >>> BTW, a blog post explaining the rationale behind yamldt is going to come >>> up soon at our website, I’ll post the link when it does. >> >> Cool. I see it got posted, but didn’t get a chance to read it before I >> got on this airplane. Will try to read this evening. >> >> (BTW, I’m arriving at about 11:00 tonight) >> > > Have a safe flight, you’ll get to beat me up tomorrow :) See you tomorrow. It will be good to catch up. g. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: [RFC] yamldt v0.5, now a DTS compiler too Date: Sun, 22 Oct 2017 20:13:53 +0100 Message-ID: References: <1506628736.28192.9.camel@hp800z> <744E94DE-E4AE-425B-9B02-E0E022017450@konsulko.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <744E94DE-E4AE-425B-9B02-E0E022017450-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Pantelis Antoniou Cc: David Gibson , Devicetree Compiler , Frank Rowand , Franklin S Cooper Jr , Geert Uytterhoeven , Linux Kernel Mailing List , Marek Vasut , Matt Porter , Phil Elwell , Rob Herring , Simon Glass , Tom Rini , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.org On Sun, Oct 22, 2017 at 7:23 PM, Pantelis Antoniou wrote: > Hi Grant, > >> On Oct 22, 2017, at 19:54 , Grant Likely wro= te: >> >> On Fri, Oct 20, 2017 at 8:16 PM, Pantelis Antoniou >> wrote: >>> Hi Grant, >>> >>>> On Oct 20, 2017, at 20:46 , Grant Likely w= rote: >>>> >>>> On Thu, Sep 28, 2017 at 8:58 PM, Pantelis Antoniou >>>> wrote: [...] >>> Yes. This is expected. I don=E2=80=99t think pure YAML form is a good m= atch for all >>> the crazy things that are possible (and actually used in practice) with= DTS. >> >> I don=E2=80=99t think it is as dire as that. The DTS structure is not co= mplex >> and I think can easily be mapped into pure YAML. But, it does require >> treating the DTS structure separately from its semantic meaning. For >> example, the grammar of nodes, properties and labels easily maps to >> pure YAML, but phandles and overlay trees have semantic meaning that >> must be resolved by DT specific code. I=E2=80=99ll respond to you=E2=80= =99re specific >> examples below=E2=80=A6 >> > > We are in complete agreement here. Single nodes and properties map to YAM= L perfectly. > It=E2=80=99s the complex way that we build the complete DTB that stress t= he YAML structures. Okay, good. >>> If we were to force YAML/DT file to be regular YAML files parseable by = everything >>> we=E2=80=99d have to rethink a lot of conventions that DT files current= ly use and I=E2=80=99m afraid >>> a machine translation from DTS to YAML might not be feasible then. >>> >>> OTOH moving to that model might make it possible to use YAML constructs= that are not >>> mapped at all to DTS. For instance >>> >>> - foo: true >>> bar: =E2=80=9Cstring=E2=80=9D >>> >>> - foo: false >>> bar: =E2=80=9Canother-string=E2=80=9D >>> >>> is not possible to be mapped to a DT node/property structure right now. >> >> I=E2=80=99m not following. Are you saying DT has no way to encode a list= of >> nodes? What use case are you imagining? >> > > This threw me off too at first. > > The problem is when you try to convert this into a live tree structure. > > The YAML encoding is > > +SEQ > +MAP > =3DVAL :foo > =3DVAL :true > =3DVAL :bar > =3DVAL "string > -MAP > +MAP > =3DVAL :foo > =3DVAL :false > =3DVAL :bar > =3DVAL "another-string > -MAP > -SEQ > > So it=E2=80=99s a sequence of MAPs. > > In a live tree DTS form would be > > noname-property =3D { foo=3Dtrue; bar =3D =E2=80=9Cstring=E2=80=9D; }, { = foo =3D false; bar=3D=E2=80=9Canother-string=E2=80=9D; }; > > We don=E2=80=99t have the capability as right now to express something li= ke this. > > Namely properties containing nodes, and the root of the live tree not bei= ng a node. Ah, so you're proposing property data that encodes key/value pairs, correct? Effectively adding another layer of namespace under a property, but that namespace is invisible to and generic DT parsing code in an OS (for how DT is defined today). I would straight out make that structure illegal in the YAML DT metaschema until such time as the semantics are defined. For now properties should only be allowed to contain scalars, or lists of scalars/lists which can be nested. [...] >>>> The encoding differentiates between nodes and properties implicitly >>>> base on whether the contents are a map, or a scalar/list. This does >>>> mean any parser needs to do a bit more work and it may impact what can >>>> be done with validation (I'm not going to talk about validation in >>>> this email though. We'll talk next week.) >>> >>> Hmm, I=E2=80=99m not sure I follow this. Is that related to the metadat= a problem. >> >> It has to do with iterating over properties or nodes. Nodes and props >> are mixed together, and any code processing them has to explicitly >> check the type to differentiate between the two. The alternative would >> be to collect all properties under a single key: >> >> parent: >> $props: >> foo: hello >> bar: world >> child1: {} >> child2: {} >> > > That=E2=80=99s no problem. It does look weird though. I am using the same= parser > for parsing bindings and this might make the files a little bit weird. That it does. I don=E2=80=99t feel strongly about either approach, but I wa= nt to see how the different encodings affect doing the schema bits. > > Keep in mind that we have two YAML formats to parse; the hardware descrip= tion > and the bindings describing them. Three! Hw description, schema & metaschema. :-) But metaschema should be a normal jsonschema file. > >>> >>> BTW, a blog post explaining the rationale behind yamldt is going to com= e >>> up soon at our website, I=E2=80=99ll post the link when it does. >> >> Cool. I see it got posted, but didn=E2=80=99t get a chance to read it be= fore I >> got on this airplane. Will try to read this evening. >> >> (BTW, I=E2=80=99m arriving at about 11:00 tonight) >> > > Have a safe flight, you=E2=80=99ll get to beat me up tomorrow :) See you tomorrow. It will be good to catch up. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html