On Thu, Sep 20, 2018 at 03:49:55PM +1000, Stewart Smith wrote: > 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). Note that you will need both sides of the input to be in dtb format before converting to dts for comparison. One of the consequences of the recent change is that -I dts -O dts will now mostly preserve formatting details of the input which could be lost if going via a dtb: that's kind of the point of them, indeed. But it means that if you had one dtb and one dts, comparing them directly might show spurious differences because the formatting dtc gets from the input dts doesn't match it's guesses for how to format the decompiled dtb. -- 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
