[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH 28/58] device tree: give dt more size
From: |
Alexander Graf |
Subject: |
Re: [Qemu-ppc] [PATCH 28/58] device tree: give dt more size |
Date: |
Thu, 15 Sep 2011 17:00:41 +0200 |
Am 15.09.2011 um 13:03 schrieb David Gibson <address@hidden>:
> On Thu, Sep 15, 2011 at 09:37:48AM +0200, Alexander Graf wrote:
>>
>> On 15.09.2011, at 05:19, David Gibson wrote:
>>
>>> On Wed, Sep 14, 2011 at 10:42:52AM +0200, Alexander Graf wrote:
>>>> We currently load a device tree blob and then just take its size x2 to
>>>> account for modifications we do inside. While this is nice and great,
>>>> it fails when we have a small device tree as blob and lots of nodes added
>>>> in machine init code.
>>>>
>>>> So for now, just make it 20k bigger than it was before. We maybe want to
>>>> be more clever about this later.
>>>
>>> In fact, one of the few things I can think of that might justify
>>> qemu's "abstraction" of the libfdt interface, is that the wrappers
>>> could be modified to detect -FDT_ERR_NOSPACE and realloc()
>>> appropriately.
>>
>> Oh, yeah, that sounds like a very good idea!
>>
>>> Otherwise the wrappers, which are limited and not notably simpler to
>>> use than the raw libfdt functions seem pretty pointless to me.
>>>
>>> Not that I'm biased as the author of libfdt or anything :).
>>
>> I agree that the wrappers are not all that overly useful atm. I was
>> actually very close to just ripping them out completely instead of
>> extending them for new functionality. I did have the feeling that
>> wrapping libfdt would give us a few benefits, maybe even the chance
>> of getting rid of #ifdefs in target code.
>
> Hrm, maybe. Can't really see it. Of course, my preference would be
> to get rid of those #ifdefs by embedding libfdt in qemu so it's always
> there.
It's a library and should be treated that way. But yeah, I'm inclined to fail
configure for ppc when libfdt can't be found too.
>
>> Could you please put this on your todo list? We should probably
>> force every target code in QEMU to only use the wrappers and
>> dynamically realloc() in them.
>
> Uh, sure, but it's a long list and it won't be near the top.
>
> The wrappers would need to be a lot more extensive to do this. I use
> libfdt directly in the spapr code for a reason.
Expensiveness is not too bad here, no? It should still be fast.
Also, I'm perfectly fine with this being low on the list.
Alex
>
- [Qemu-ppc] [PATCH 56/58] PPC: Fix via-cuda memory registration, (continued)
- [Qemu-ppc] [PATCH 56/58] PPC: Fix via-cuda memory registration, Alexander Graf, 2011/09/14
- [Qemu-ppc] [PATCH 06/58] PPC: Extend MPIC MMIO range, Alexander Graf, 2011/09/14
- [Qemu-ppc] [PATCH 54/58] openpic: Unfold write_IRQreg, Alexander Graf, 2011/09/14
- [Qemu-ppc] [PATCH 18/58] PPC: E500: Remove mpc8544_copy_soc_cell, Alexander Graf, 2011/09/14
- [Qemu-ppc] [PATCH 07/58] PPC: Fix IPI support in MPIC, Alexander Graf, 2011/09/14
- [Qemu-ppc] [PATCH 36/58] pseries: Bugfixes for interrupt numbering in XICS code, Alexander Graf, 2011/09/14
- [Qemu-ppc] [PATCH 28/58] device tree: give dt more size, Alexander Graf, 2011/09/14
[Qemu-ppc] [PATCH 34/58] PPC: Enable to use PAPR with PR style KVM, Alexander Graf, 2011/09/14
[Qemu-ppc] [PATCH 41/58] pseries: Add real mode debugging hcalls, Alexander Graf, 2011/09/14
[Qemu-ppc] [PATCH 17/58] PPC: E500: Use generic kvm function for freq, Alexander Graf, 2011/09/14
[Qemu-ppc] [PATCH 05/58] PPC: Add CPU local MMIO regions to MPIC, Alexander Graf, 2011/09/14
[Qemu-ppc] [PATCH 47/58] Implement POWER7's CFAR in TCG, Alexander Graf, 2011/09/14