From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank Rowand Subject: Re: devicetree repository separation/migration Date: Wed, 19 Feb 2014 13:32:40 -0800 Message-ID: <530522F8.8050102@gmail.com> References: <20140217180544.GU7862@titan.lakedaemon.net> <20140218155750.GS17250@pengutronix.de> <20140218181854.GB7862@titan.lakedaemon.net> Reply-To: frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: devicetree-spec-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rob Herring Cc: Tim Bird , Olof Johansson , Jason Cooper , Sascha Hauer , Grant Likely , Ian Campbell , Pawel Moll , Mark Rutland , Kumar Gala , Rob Landley , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@vger.kernel.org On 2/19/2014 1:12 PM, Rob Herring wrote: > On Tue, Feb 18, 2014 at 4:44 PM, Tim Bird wrote: >> I'm not in favor of separating the device tree information from the kernel. >> >> If we switch, then whatever synchronization issues other projects >> are having now with synching with the device tree info from the kernel will >> just then become the problem of the kernel developers, who will then >> have to sync with the device tree info from another repository. If the >> sync issues can't be solved now for them, why or how would it be solved >> post-separation for us? (It sounds like a zero-sum game of pain transfer >> to me.) >> >> I'm relatively unfamiliar with the arguments. Can someone provide >> a brief list of reasons this is needed, and how the inconvenience to Linux >> kernel developers will be minimized, should it proceed? > > - Primarily, other projects like u-boot, barebox, FreeBSD and possibly > TianoCore (UEFI) are using DT now. Leaving them in the kernel will > cause fragmentation. The statements about barebox needing to add > barebox properties to the dtb is exactly the kind of fragmentation I'm > worried about. "Devicetree only describes the hardware" (paraphrasing a claim often made). If the linux kernel dts files do not fully describe the hardware then it is appropriate to add the missing info. > - The need to share dts fragments across arches. This is a bit > orthogonal, but this restructuring would be easier done outside the > kernel tree. Restructuring everything in the kernel tree and then > moving it out would be a lot of churn. The churn will occur no matter what repository the files are in. > - As we add schema checking, we need somewhere to put those. And why does _that_ need to be in an external repository? > > One way to minimize the inconvenience is keep versioning and dev > cycles in sync with the kernel. We could also start doing things to > align the kernel workflow with how things will work when we do have a > separate repository. If you stay in sync with the kernel then you are still tied to the linux kernel source repository. No gain. -Frank -- To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html