On Wed, Feb 19, 2014 at 3:32 PM, Frank Rowand <frowand.list@xxxxxxxxx> wrote: > On 2/19/2014 1:12 PM, Rob Herring wrote: >> 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. > > "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. Yes, but if hardware description is what is being added, then that is not bootloader specific. I would guess this case is not h/w description, but I don't know as none of it has been posted for review. The real problem here is adding bindings without review. Not fully describing the h/w and adding to the dts is common and not really an issue as long as it is done in an ABI compatible way. >> - 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. Yes, but doing this in the kernel is much harder to coordinate with Linus and architecture maintainers. I don't think we want to go thru that process when we plan to just remove everything. >> - As we add schema checking, we need somewhere to put those. > > And why does _that_ need to be in an external repository? For the same reason as everything else (binding docs, dts files), so people outside of kernel developers will contribute. >> >> 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. The only synchronization would be tagging the repo at the same time and using the same version numbering. Using that versus working on master all the time would be completely up to end users. It's really only encouraging people to test a specific combination of kernel and dtb. The other option is we simply make up our own tagging/release scheme. 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
