Re: [Xen-devel] [PATCH v8 1/6] tools/libxl: Check if fdt_{first, next}_subnode are present in libfdt

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-05-13 at 16:22 +0100, Julien Grall wrote:

> :(. Both the distribution are using an old version of libfdt where the 3
> prototypes are defined but the implementation is not exposed in the
> library (this is because they use a whitelist for building it)
> 
> I gave look to see if we can import them from libfdt. It will require to
> import few others in order to make them work:
>       - _fdt_check_node_offset
>       - _fdt_offset_ptr
>       - _nextprop
> 
> I think we can skip the first one because it's only a validity check.
> FWIW, we declared the the partial device tree should be trusted so valid.
> 
> Nonetheless we would add 5 more functions (+ the actual 2) in libxl
> which represents ~50 lines of codes.
> 
> The 3 offending function have been correctly exposed since the version
> v1.4.0 released in June 2013.
> 
> I gave a look to major distribution to see which version is using an old
> version of libfdt (i.e < 1.4.0:
>       - Centos: < Centos 6
>       - Debian: < Jessie => Wheezy using an old version
>       - Fedora: < Fedora 20
>       - openSuse: < opensuse 13.1
>       - ubuntu: < Ubuntu 14.04 => The LTS (14.04) is using a new version
>       - RedHat: < Redhat 6
> 
> AFAICT, all major distributions except debian (for wheezy) are using a
> libfdt > v1.4. So I would suggest to disable the partial device tree
> support on distribution using older version.

OK, I think we can live with this.

> If the user want to use platform device passthrough it would have either
> to build a newer version of libfdt or append a device tree to the guest
> kernel.
> 
> Note: IIRC osstest is using wheezy. If so, we won't be able to test
> platform device passthrough until the distribution version is upgraded.
> 
> Although, we don't currently have a platform supporting non-PCI
> passthrough in osstest.

Right, I'd expect us to have upgraded to Jessie before we got hold of
such production hardware anyway.

Ian.


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