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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Jul 2013 13:44:42 -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: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.

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.

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/