Re: devicetree repository separation/migration

On Tue, Feb 18, 2014 at 4:44 PM, Tim Bird [off-list ref] 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-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html