On Thu, Jul 27, 2017 at 08:51:40PM -0400, Tom Rini wrote: > On Thu, Jul 27, 2017 at 06:00:00PM -0500, Rob Herring wrote: > > On Thu, Jul 27, 2017 at 4:46 PM, Pantelis Antoniou > > <pantelis.antoniou@xxxxxxxxxxxx> wrote: > > > Hi Frank, > > > > > > On Thu, 2017-07-27 at 13:22 -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. > > >> > > > > > > This has nothing to do with the kernel. It spits out valid DTBs that the > > > kernel (or anything else) may use. > > > > Let me rephrase Frank's statement: this is not a good idea for the > > main repository of dts files. > > > > But sure, DTS is already not the only source of DTBs. It comes from > > firmware on Power systems. > > Yes, but unless they're generated from something other than a (at the > time) normal DTS, that's not a good example, IMHO. > > > > If you want to create and maintain your own > > source format, then that is perfectly fine. But based on the current > > understanding, I'm not seeing a reason we'd convert DTS files to YAML. > > Can I propose one? To borrow a phrase, Validation, Validation, > Validation. Let me point to fe496e23b748 in the kernel for a moment. I > found that as part of helping a new engineer come up to speed on doing > device tree work. What I found was a case where: > - The binding doc gives one value for compatible as the required value. > - The code accepts only a single, different value. > - A few in-kernel dts files have different still values. > > If the common dts source file was in yaml, binding docs would be written > so that we could use them as validation and hey, the above wouldn't ever > have happened. And I'm sure this is not the only example that's in-tree > right now. These kind of problems create an artificially high barrier > to entry in a rather important area of the kernel (you can't trust the > docs, you have to check around the code too, and of course the code > might have moved since the docs were written). Yeah, problems like that suck. But I don't see that going to YAML helps avoid them. It may have a number of neat things it can do, but yaml won't magically give you a way to match against bindings. You'd still need to define a way of describing bindings (on top of yaml or otherwise) and implement the matching of DTs against bindings. > > Maybe you're not proposing that now, but if that is not the end goal I > > don't see the point of a new format. If YAML solves a bunch of > > problems, then of course we'd want to convert DTS files at some point. > > To borrow that same phrase again, Tooling, Tooling, Tooling. The > current dts format is a niche format. That's great, our community > is basically responsible for all tooling, we can do what we want. > That's also awful, we're the only people that care about tooling and we > all have lots of other itches to scratch. There are so so so many > editors that just know YAML and will work it into the rest of the > development environment someone is using. Up to a point. YAML isn't so much a format as a framework for making formats based on the JSON data model. Some yaml tools will be usable, but only if they're flexible enough to cope with the particular way that DTs use yaml. > None of that exists for our > dts format. Who cares about that? Engineers that aren't primarily > writing dts files. I'm pretty sure every engineer that's written / > extended a dts file has made an "invisible" mistake that would have been > caught with a different source format that had validation already. > > And we've been talking about validation for ages now. We'll probably > still be talking about it for ages more (as it's hard > thanked-at-conferences-and-such work!), until it reaches the point where > anyone can pick up a current binding and re-format it into yaml for > validation. > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
