Re: [RFC] dtc: Optionally sort nodes and properties

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Wed, Sep 08, 2010 at 03:39:52PM -0500, Scott Wood wrote:
> On Wed, 8 Sep 2010 14:25:30 -0600
> Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> 
> > On Wed, Sep 01, 2010 at 12:47:18PM +1000, David Gibson wrote:
> > > Hi folks,
> > > 
> > > Here's a patch I made for dtc a little while ago, and I'm not sure if
> > > it's something that sensibly ought to be merged into mainline dtc.
> > > 
> > > The patch adds a '-s' option to dtc, which causes it to "sort" the
> > > tree before output.  That is, it sorts the reserve entries, it sorts
> > > the properties within each node by name, and it sorts nodes by name
> > > within their parent.
> > > 
> > > The main use for this is when looking at the differences between two
> > > device trees which are similar, except for semantically null internal
> > > rearrangements.  Directly diffing the dts files will give a lot of
> > > noise due to the order changes, but running both trees through dtc -s
> > > then diffing will usually give a pretty sensible summary of the
> > > changes (it can still be confused by node name changes, of course).
> > 
> > As discussed on IRC, I'm not thrilled with adding this as a
> > user-visible option because sorted trees aren't actually useful or
> > desirable (and in some cases undesireable) except for the use-case of
> > comparing trees.  However, being able to compare unsorted trees is
> > still a use case that is very much needed, so I'm okay with this patch
> > until we come up with something better.
> > 
> > Although maybe the -s option should remain undocumented; or at least
> > warn people away from using it.
> 
> If it's undocumented, how would people find out how to compare device
> trees?

Comparing trees should be its own documented command.  If it happens
to be implemented as a shell script using this option, then that is
just fine by me.

What I don't want is people thinking that sorting their trees by
default is a good idea.  (Although the idea of randomly sorting trees
is vaguely interesting.  It would certainly expose all kinds of weird
bugs in the kernel where we depend on the natural sorting for driver
probe order)

> Maybe just add a "(for comparing trees)" note in the help text to
> clarify the intended purpose?

That's fine too.  It's not something worth debating a long time over.

g.