qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] device_tree: Add qemu_fdt_totalsize function


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH] device_tree: Add qemu_fdt_totalsize function
Date: Sun, 6 May 2018 23:39:55 +1000
User-agent: Mutt/1.9.3 (2018-01-21)

On Sun, May 06, 2018 at 01:23:30PM +0100, Peter Maydell wrote:
> On 5 May 2018 at 22:59, Michael Clark <address@hidden> wrote:
> > Okay, so an alternative is to call fdt_pack() and then fdt_totalsize().
> > Thanks!
> >
> > QEMU has its own wrapper around libfdt and neither the fdt_pack() nor
> > fdt_totalsize() functions are exposed.
> >
> > Some architecture use only the wrapper functions provided by
> > qemu/include/include/sysemu/device_tree.h
> >
> > It seems that target/ppc has #include <libfdt.h> and calls fdt_pack() and
> > fdt_totalsize() directly.
> 
> Yeah, I find this combination of libfdt direct access and a
> QEMU wrapper layer a bit confusing. I think it's grown more
> than it's been actively designed.

Absolutely.  I think the history is that when fdt was first used, the
layer was created as an (arguably) simpler wrapper.  But, it was very
limited.  Once you start doing more complex things, there's no great
advantage to using that limited wrapper over the raw library, hence
the direct usage.  At least, that's what I think though I'm obviously
a) already familiar with the libfdt interface and b) biased.

> Your approach of doing
> direct calls to pack/totalsize is fine. Maybe the wrapper
> layer could be improved some day too.

Well, I'm biased of course, but I think we'd be better off just
ditching the wrapper.  In its present form it is so limited as to not
really add any value.  If it was rewritten to do something useful
(e.g. handling reallocations), I think it would be even better if
done as an extension to libfdt itself so it can benefit everyone, not
just qemu.

Although, that said, I'll re-iterate that I think qemu's fdt
manipulation is now sufficiently complex that it would be better off
using a "live" (dynamically allocated & pointer based) tree
representation that we just flatten immediately before loading it into
the guest.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]