On Tue, Feb 18, 2014 at 4:44 PM, Tim Bird <tbird20d@xxxxxxxxx> 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. - 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. - As we add schema checking, we need somewhere to put those. 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. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
