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). > 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. 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. -- Tom
Attachment:
signature.asc
Description: Digital signature
