Message-ID: <51EED94C.9070500@gmail.com>
Date:	Tue, 23 Jul 2013 14:28:12 -0500
From:	Rob Herring <robherring2@...il.com>
To:	Ian Campbell <ian.campbell@...rix.com>
CC:	Stephen Warren <swarren@...dotorg.org>,
	Pawel Moll <pawel.moll@....com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mark Rutland <Mark.Rutland@....com>,
	Olof Johansson <olof@...om.net>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership

On 07/23/2013 01:55 PM, Ian Campbell wrote:
> 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.
> 
> Right. The advantage of scripting, even if that script is just a big
> long list of manual rules, is that we can preserve the history from
> linux.git in device-tree.git, so git annotate etc say something useful.
> 
> But if I'm going to write a big long list of such rules I'd like to only
> do the bulk of the work once, so we need to decide on the layout first.
> 
>>  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.
>>
>> 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.
> 
> I don't really have a strong opinion on the layout myself, I'm happy to
> implement whatever works for people.
> 
> The board level compatible string vendor is the top-level compatible,
> right? e.g.:
>         / {
>                 model = "Calxeda Highbank";
>                 compatible = "calxeda,highbank";
> "calxeda,highbank" in this case. So you propose s|,|/| on that so the
> file ends up in calxeda/highbank.dts?

Well, I was thinking just taking the vendor name and keep the existing
filename, but getting some consistency in filenames would probably be
good as well.

> For the included ecx-common.dtsi I think you are proposing to find all
> the files which include it and then find the
> deepest-common-subdirectory? In this case the other include is
> ecx-2000.dts which is compatible calxeda,ecx-2000
> (->calxeda/ecx2000.dts) so the common subdir is calxeda and dtsi would
> become calxeda/ecs-2000.dtsi. That works, I should probably have picked
> an example which didn't rely on files you are so involved with in case
> there is a selection bias at work ;-)

Yes, Calxeda stuff is obviously a simple example, but I don't think we
have any/many examples of includes across SOC vendors. Where things
breakdown are 3rd party boards. Do those go in the board or SOC vendor
directory? I'd vote for SOC vendor dir to keep the include structure
simple. That may still have issue if there are includes for
daughterboards which support multiple vendors' SOCs.

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

Powered by blists - more mailing lists