Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

[Ian Campbell]

On Tue, 2013-07-23 at 13:44 -0500, Rob Herring wrote:
> On 07/23/2013 01:09 PM, Ian Campbell wrote:
> > On Tue, 2013-07-23 at 10:59 -0700, Stephen Warren wrote:
> > 
> >> I think the solution is to introduce some new shared/common location for
> >> shared/common *.dtsi files, into the kernel tree, in the interim.
> >>
> >> When *.dts move out of the kernel, this common location can simply be
> >> consumed as part of the DT tree re-organization.
> >>
> >> Or perhaps, we could move *.dts around in the kernel to match the
> >> proposed DT tree structure before that point in time?
> > 
> > FWIW I can easily handle any transformation as part of the automated
> > extraction into the device-tree.git. If it can expressed as a sed script
> > then so much the better, e.g. the current rules are
> > http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git;a=blob;f=scripts/rewrite-paths.sed;h=f7a157d1b486bac058f50e42cf7bedc8630e54ff;hb=HEAD.
> > If it gets too complicated for sed I can always switch to something
> > else.
> > 
> > I'm already pending a complete rebuild of the export to add in the
> > Documentation/devicetree/bindings sub tree but since it takes an age to
> > run I was waiting for the output of this conversation before kicking
> > that off.
> 
> I'd doubt we could completely script this with a generic rule without a
> bunch of manual transformations. So I think either restructuring in the
> kernel or when we move them out of the kernel makes more sense. We know
> the problem is coming, but it is not yet a major, pressing issue.

So in the end I rebuilt with the existing transformation plus rewirting
Documentation/devicetree/bindings/ onto Bindings. I've pushed the new
branches to
        
        http://xenbits.xen.org/gitweb/?p=people/ianc/device-tree-rebasing.git
        git://xenbits.xen.org/people/ianc/device-tree-rebasing.git

In keeping with the name this means that the master and upstream/dts
branches have been rebased and so updates will be non-fastforwarding (as
has the internal filter-state branch). As you would expect the tags have
all changed as well.

> OTOH, you could see how far you get by putting dts files in directories
> by their board level compatible string vendor and put any include files
> where ever they are included from. Of course, that is just my proposed
> layout. I haven't heard any opinions on that layout.

These sorts of more complicated transformation aren't really feasible to
implement in the current automatic conversion process. It tries to
retain full history for the affected files (so git annotate/log/etc are
useful) which is OK for rewriting based solely on the path but once you
have to inspect the actual contents it gets more complicated and
significantly slower (since git rewrite-branch has to checkout every
tree, even without this it takes 2 days or so to convert).

These conversions would be better off done either as a second, probably
also automated, shuffling after (perhaps immediately after) we cut over
to using device-tree.git as the primary home.

If we end up doing some restructuring while these files are still in the
kernel I think I can still cope with that.

Ian.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/