Re: [RFC] [PATCH V2] Adding DTB to architecture independent vmlinux

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

On Fri, Oct 29, 2010 at 01:29:07PM -0700, H. Peter Anvin wrote:
> On 10/28/2010 09:04 PM, David Gibson wrote:
> > On Thu, Oct 28, 2010 at 02:44:47PM -0700, H. Peter Anvin wrote:
> >> On 10/28/2010 10:32 AM, David VomLehn wrote:
> >>>
> >>> In my case, where there are a lot of up-front reservations of memory
> >>> at a static address, there is a fair amount of work to do before
> >>> it's possible to do the dynamic address allocation for the blob's
> >>> ultimate destination, but I'm okay with either doing blob size and address
> >>> rounding or copying it from init. I don't see a benefit of supporting
> >>> multiple approaches for Linux.
> >>>
> >>
> >> The reason I mentioned dynamic allocation is that you still need to do
> >> dynamic allocation if you're using a blob from an external source.  If
> >> you don't end up with pointers *into* the blob, though, then you don't
> >> need to do the relocation until some time before you jettison the init
> >> section.
> > 
> > The way the dtb format is designed, you should almost never work with
> > pointers into the the middle of the blob.
> 
> "Almost never"?  That scares me when I hear it...

Heh, understandable.  So, the dtb format is such that you want to work
with internal offsets most of the time, not pointers into the middle.
Except that of course, you will use transient internal pointers to
grab pieces from the dtb - it's just best to avoid passing them around
whenever you can.

The other case is that once the dtb is "frozen" (no more changes), it
can be useful to keep around pointers to bits of data within the dtb,
rather than duplicating each such thing in its own allocated buffer
somewhere.  e.g. I think once we unflatten the tree in powerpc,
property values will still actually point to within the original dtb.

-- 
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