Re: [Qemu-devel] [PATCH 07/31] dt: add helper for phandle allocation

[Scott Wood]

On 06/06/2012 07:15 PM, Peter Crosthwaite wrote:
> On Thu, Jun 7, 2012 at 2:55 AM, Scott Wood <address@hidden> wrote:
>> On 06/06/2012 11:00 AM, Alexander Graf wrote:
>>> On 06/06/2012 07:18 AM, Peter Crosthwaite wrote:
>>>> On Wed, 2012-06-06 at 01:52 +0200, Alexander Graf wrote:
>>>>> +uint32_t qemu_devtree_alloc_phandle(void *fdt)
>>>>> +{
>>>>> +    static int phandle = 0x8000;
>>>> can easily double check for duplicates. Would also allow you to start
>>>> from 1 rather than magic number 0x8000?
>>
>> You can't check for duplicates, because the tree fragments you'll be
>> conflicting with haven't been added to the tree yet.  That's done by a
>> tool operating on the tree output by the first pass of qemu, and is fed
>> back into the second pass of qemu.
>>
> 
> Im not sure what you mean by "fragments [which] havent been added to
> the tree yet"?

The use case I have in mind is running QEMU once in dumpdtb mode,
merging in fragments from the host device tree for directly assigned
devices, and passing the result back to a second invocation of QEMU.

For the first pass of QEMU, the managing tool would look at the host
device tree to determine a suitable phandle range to pass to QEMU.

> Im thinking here of the use model where you use the DTB
> API to modify and existing DTB (probably pc-bios/foo.dtb). Yes, for
> Alex's series im not sure it wins anything as you are starting a DTB
> from scratch (which will have no pre-existing phandles), but it guards
> against a potentially very obscure and hard to find bug in some other
> potential uses of this API.

I'm not sure the API misuse it would protect against is particularly
likely -- you'd have to have some phandle creators ignore the API, and
others use the API, and the misbehaving phandle generator has to do its
thing before the conflicting API-compliant phandle generation.  Doing a
phandle search is a fairly heavy operation, which may not be the biggest
concern here, but still it shouldn't be called trivially.

It would be different if QEMU were adding nodes to an existing tree,
rather than creating a tree from scratch.

In any case, it doesn't eliminate the need for passing in a starting point.

-Scott