David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> writes: > On Fri, Sep 14, 2018 at 02:50:36PM +1000, Stewart Smith wrote: >> Hi! >> >> It appears that 32b9c61307629ac76c6ac0bead6f926d579b3d2c has introduced >> a couple of regressions in the DTS output: >> >> For a start, I get >> compatible = "ibm,powernv\0ibm,firenze"; >> Rather than >> compatible = "ibm,powernv", "ibm,firenze"; >> (which is what I'd expect, and what's in the dts) >> >> Additionally, the whitespace is different: >> phandle = <0x44>; >> versus, now: >> phandle = < 0x44 >; >> >> which breaks diffing the dts, which has proved a rather nice unit test >> for my device tree producing firmware. > > So Grant has patches addressing at least some of this, as you've > probably seen. > > But, really, if what you're doing is broken by format changes in the > dts output, you're doing something wrong in the first place. Apart > from the fact that relying on exact whitespace is always likely to be > fragile, how -Odts chooses to format things has *always* been a > heuristic subject to change. It really can't be anything else, since > the dts to dtb conversion is (slightly) lossy. > > The patches we've applied recently *will* still change the formatting > - generally making it more likely to match the original dts. But, if > you're comparing -O dts output with a pre-generated dts you're still > asking for trouble. > > What you really want to do here is compare the dtbs, since that's the > content you actually care about. I get that you want to have a > human-readable diff, but you can do that by generating the dtbs to > compare first, then comparing -O dts output with -O dts output. As > long as you generate both at the same time, you're using the same set > of heuristics to format the output, so you can be confident they'll > compare reasonably. It's comparing -O dts output with a hand written > dts file, or with a dts file generated at a different time with a > different dtc version that's the problem. > > dtc already includes a 'dtdiff' script to do exactly this (it also > ignores ordering differences in the dtbs, since that's not > semantically meaningful). Yes, that makes a lot more sense. I'll rework things to use dtdiff in that way. It sounds like that should be a lot more solid than what's there currently (even if it has worked fine for ~4 years). -- Stewart Smith OPAL Architect, IBM.
