[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

-anil

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.