Am 15.09.2011 um 13:03 schrieb David Gibson <da...@gibson.dropbear.id.au>:
> 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 >
