RFC: Location for Device Tree Sources?
Mark A. Greer
mgreer at mvista.com
Thu Aug 3 04:24:15 EST 2006
On Wed, Aug 02, 2006 at 08:35:55AM -0500, Kumar Gala wrote:
>
> On Aug 1, 2006, at 10:20 PM, Grant Likely wrote:
>
> > On 8/1/06, Josh Boyer <jwboyer at jdub.homelinux.org> wrote:
> >> On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
> >>> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
> >>>> On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
> >>>>>
> >>>>> Mark A. Greer in his patch to port sandpoint to arch/powerpc put
> >>>>> sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
> >>>>
> >>>> I believe in his latest patches he removed this part. The device
> >>>> trees
> >>>> were not included at all and he left this point open for
> >>>> discussion.
> >>>
> >>> That's correct.
> >>>
> >>> TBH, I think its wrong to keep them in the kernel source at all--
> >>> yes,
> >>> the same argument could be made for arch/powerpc/boot but that's
> >>> been
> >>> settled.
> >>
> >> Sorry, I have to disagree. We're talking about device tree _source_
> >> files here. I believe they should be included in the kernel source.
> >> Where that is, I don't have a particularly strong argument but they
> >> should be included.
> >
> > I have to second that opinion. The device tree is absolutely integral
> > with the rest of the code/drivers needed to support a board. I say
> > there are stronger arguments for keeping the dts files in the kernel
> > source than there are for the boot wrapper.
> >
> > powerpc/boot/dts makes a lot of sense to me.
>
> I like this location and agree that having them in tree makes sense.
> And putting them under boot isolates them from the kernel proper.
>
> The reason I see to having them in tree is to ensure proper version
> compatibility. This way there is no concern about which .dts version
> will work with which kernel. In the future we can always pull them
> out when things are more stable.
Hmm, that is a good reason...
Mark
More information about the Linuxppc-dev
mailing list