Re: [PATCH dtc] Implement the -R option and add a -S option.

[Jerry Van Baren <gvb.uboot@gmail.com>]

David Gibson wrote:
> On Sat, Apr 14, 2007 at 10:13:49PM -0400, Jerry Van Baren wrote:
>> David Gibson wrote:
>>> On Sat, Apr 14, 2007 at 08:58:49AM -0400, Jerry Van Baren wrote:
>> [snip]
>>
>>>> On an unrelated related note, I don't believe my -R additions are 
>>>> actually putting out additional reserve map slots (easiest to see using 
>>>> the asm format output).  I'm still trying to understand why not, it 
>>>> seemed pretty straight-forward.  When I implemented it, I was looking at 
>>>> hexdumps of the dtb binary format and looking at the header and thought 
>>>> I had it working... using it with my u-boot mods shows no extra reserved 
>>>> slots.  I'm looking into where I went wrong.
>>> Be careful to check the actual offsets.  Bear in mind that objdump may
>>> elide zero words.  Also bear in mind that the only way a reader of the
>>> device tree has of counting the number of reserve entries is stepping
>>> through until it hits the terminating (0,0), so the extra entries will
>>> just look like an early termination of the list.  In this sense -R
>>> doesn't add "extra slots", but just ensures that there is space after
>>> the reserve map to add more entries.
>> Hi David,
>>
>> It actually is OK, went back and verified it.  I needed to modify the 
>> asm output to implement the -R extra slots which was confusing me (patch 
>> that you didn't like the calloc in ;-).
>>
>> The calloc change was actually window dressing, I was just being 
>> paranoid about a binary blob that is bigger than its contents (has extra 
>> space).  The unused space is unused, so it doen't really matter if it is 
>> non-zero.  I'll roll a new version.
> 
> Oh, I think zeroing it is correct, I'd just prefer it was done at the
> callsite, rather than within xmalloc().  Strictly speaking you're
> right, what's in the extra area shouldn't matter, but I don't like the
> idea of potentially leaking random memory contents to file, which I
> think could happen without a memset().  Because dtc is unpriveleged it
> shouldn't actually matter, but it's ugly and a bad habit to establish.

Where I got concerned was a conversion of a .dtb input into a .dts or 
.asm output (or even a .dtb output).  I've run it and verified that the 
extra space (which is potentially random garbage) is not copied to the 
output - the size in the header is what it is and the data output is 
only the actual data (no major surprise there).

Generating a text output format actually strips the extra size/data 
because dtc turns it back into a symbolic form and padding is outside of 
the symbolic form, if you follow my drift (there isn't a way to 
represent extra blob padding in a dts format).

gvb