On Thu, Jul 27, 2017 at 01:22:24PM -0700, Frank Rowand wrote: > Hi Pantelis, > > Keep in mind one of the reasons Linus says he is very direct is to > avoid leading a developer on, so that they don't waste a lot of time > trying to resolve the maintainer's issues instead of realizing that > the maintainer is saying "no". Please read my current answer as being > "no, not likely to ever be accepted", not "no, not in the current form". > > My first reaction is: no, this is not a good idea for the Linux kernel. [snip] > >>> For more take a look here. > >>> > >>> https://github.com/pantoniou/yamldt > >> > >> Looking at the example, I find the syntax harder to follow. Parsing > >> what are node names vs labels is one. Relying on indentation for tree > >> hierarchy is another. > > I agree with Rob. > > And I don't like the YAML feature that the same information can be > expressed in very different syntax (as shown in the example immediately > below in the email I am replying to), which can result in two functionally > equivalent YAML source files looking very different - that is a big usability > issue to me. But now I'm getting to a much lower level of detail than I > want to - I want to stay mostly at the architectural level for my issues. I'd like to argue this from the opposing view point for a moment. /* * This is a valid comment. */ // And so is this. But you're only going to find one in the kernel, and that's fine. We can easily say that 'foo: { bar: true }' is what an upstream repository of dtb source files will accept. And without googling, I'm going to say I'm pretty sure since they're equivalent, $FANCYEDITORS already have a way to spit out a file in whatever format is preferred. And just like your engineer that picks up the kernel and // comments something like this, because that's what they know they can write it: like: this for their product that they never intend to submit upstream, just like they don't intend to submit the kernel changes they made upstream either. But the problem that needed solving was solved. > > > > This is really debatable. You can use curly braces if you don't like the > > indentation. > > > > I.e. > > > > foo: > > bar: true > > > > Can be written as > > foo: { bar: true } > > > > YAML is a JSON superset which uses the curly braces as a map separator. > > > > And frankly there are about x1000 more people aware of YAML syntax than > > DTS syntax. > > > >> Does C preprocessing of the YAML files work? I'm surprised if it does. > >> > > > > I think you should check the code out and see for yourself. > > > > The complete set of C preprocessing of DTS is available, and works > > perfectly AFAIKT. > > > >>> > >>> I am eagerly awaiting for your comments. > >> > >> I could see some uses here to extract data from dts files more easily. > >> For example, to extract all compatible strings for some set of dts > >> files. I did this by hacking dtc to dump them. Or as a starting point > >> to create YAML based DT binding schema. I wonder how Grant is coming > >> along with that. > > But the proposal is not to process DTS format files with this new tool. > The proposal is to convert device tree source files to a YAML format > and have the new tool compile only YAML format source files. > > Having a tool to convert DTS format to a YAML format within a validation > toll is something that has been proposed several times. If I recall > correctly, Grant had a prototype that did that step in a handful of > lines. (I'm not sure how complete that conversion process was in > his prototype form.) To emphasize what I said in another email, but wouldn't it be nice if instead of "convert DTS to YAML, run validation" it was always just "validate your DTS as part of creating your DTB, every time" ? -- Tom
Attachment:
signature.asc
Description: Digital signature
