Re: [Xen-devel] [PATCH ARM v6 05/14] mini-os: import libfdt

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-07-16 at 15:13 +0100, Anil Madhavapeddy wrote:
> On 16 Jul 2014, at 14:34, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> 
> > On Wed, 2014-07-16 at 14:02 +0100, Andrew Cooper wrote:
> >> On 16/07/14 13:29, Ian Campbell wrote:
> >>> On Wed, 2014-07-16 at 12:44 +0100, Andrew Cooper wrote:
> >>>> On 16/07/14 12:07, Thomas Leonard wrote:
> >>>>> From: Karim Raslan <karim.allah.ahmed@xxxxxxxxx>
> >>>>> 
> >>>>> Looks like this is revision v1.3.0-47-gbe60268 from
> >>>>> http://git.jdl.com/gitweb/?p=dtc.git
> >>>>> 
> >>>>> The memmove implementation is from FreeBSD's
> >>>>> contrib/ldns/compat/memmove.c (r246827).
> >>>>> 
> >>>>> Signed-off-by: Karim Allah Ahmed <karim.allah.ahmed@xxxxxxxxx>
> >>>>> [talex5@xxxxxxxxx: split out FDT support into a separate patch]
> >>>>> [talex5@xxxxxxxxx: fixed "make clean" for FDT]
> >>>>> [talex5@xxxxxxxxx: replaced GPL memmove with BSD one]
> >>>>> Signed-off-by: Thomas Leonard <talex5@xxxxxxxxx>
> >>>> Xen already has a copy of libfdt in xen/common/libfdt.
> >>> Please review the thread on this from the previous postings.
> >>> 
> >>> Ian.
> >>> 
> >> 
> >> Which appears to be unconcluded.
> > 
> > http://article.gmane.org/gmane.comp.emulators.xen.devel/205280 looked
> > conclusive to me.
> > 
> >> libfdt is a 3rd party library which, from what I can tell in the
> >> history, is unmodified.  Therefore, my suggestion of moving it outside
> >> of the xen/ tree and having both minios and Xen VPATH themselves access
> >> to it helps with the end goal of preventing minios becoming dependent on
> >> Xen code.  It further prevents both Xen and minios from accidentally
> >> gaining localisation hacks in the library itself, which makes it easier
> >> to updates to the base libdft if/when necessary.
> > 
> > This would mean that splitting extras/mini-os off wouldn't be just a
> > case of doing that, you'd also need arrange for the VPATH to be
> > satisfied, I don't know if Anil et al will be happy with that.
> 
> As long as we can resist the urge to locally modify libfdt, that shouldn't
> be too onerous.  However, if libfdt isn't being modified at all, then
> why import it into the tree at all?  We could just clone the right revision
> in the build system as happens for some other upstream tools.

That's generally a sucky approach though, I'd like to see less not more
of it.

libfdt is somewhat designed to be embedded in this way.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel