From: Jerry Van Baren <gvb.uboot@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Date: Mon, 17 May 2010 07:24:33 -0400 [thread overview]
Message-ID: <4BF12771.2050802@gmail.com> (raw)
In-Reply-To: <AANLkTilPrgpUwL630lzSmzKt5bBXFiq6zDPIiR3pQcwa@mail.gmail.com>
Timur Tabi wrote:
> On Sat, May 15, 2010 at 9:11 PM, Gerald Van Baren <gvb.uboot@gmail.com> wrote:
>
>> The code has one pre-existing weakness that bothers me: if there is
>> something following the FDT blob, it will get overwritten by the
>> increased blob. One way around this would be to malloc() a new memory
>> space and move and expand the blob to the new space. The first time
>> this was done, the original blob should not be free()ed since it wasn't
>> malloc()ed, but the second and subsequent times it should be free()ed.
>
> But then how does the caller know where the new blob is? When I call
> fdt_increase_size(), I pass it the address of a blob that I'm
> modifying. After the function returns, my value of 'fdt' is no longer
> valid.
Oops, yes, that is a pretty fatal flaw.
>> I've added this to your patch, but have *NOT* execution tested it. Does
>> this addition (a) make sense and (b) work?
>
> I was expecting the caller of fdt_increase_size() to know that the
> space after the fdt is available.
OK. I'll <acked-by> the original patch. The best way to incorporate
the patch would be for Kumar (I assume) to pick up the libfdt change
with the Freescale change that needs it so that the changes are
inherently coordinated.
gvb
next prev parent reply other threads:[~2010-05-17 11:24 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-10 21:26 [U-Boot] [PATCH 2/3] libfdt: make fdt_increase_size() available to everyone Timur Tabi
2010-05-10 21:30 ` Timur Tabi
2010-05-13 17:46 ` Kumar Gala
2010-05-16 2:11 ` [U-Boot] " Gerald Van Baren
2010-05-16 4:13 ` Timur Tabi
2010-05-17 11:24 ` Jerry Van Baren [this message]
2010-05-17 13:16 ` Wolfgang Denk
2010-05-17 14:16 ` Timur Tabi
2010-05-17 20:33 ` Wolfgang Denk
2010-05-18 14:10 ` Timur Tabi
2010-05-18 15:18 ` Wolfgang Denk
2010-05-18 15:32 ` Timur Tabi
2010-05-18 22:20 ` Wolfgang Denk
2010-05-19 0:51 ` Timur Tabi
2010-05-19 6:54 ` Wolfgang Denk
2010-05-19 14:57 ` Timur Tabi
2010-05-19 15:14 ` Wolfgang Denk
2010-05-19 15:34 ` Timur Tabi
2010-05-19 15:44 ` Wolfgang Denk
2010-05-19 21:46 ` Kumar Gala
2010-05-19 22:06 ` Wolfgang Denk
2010-05-19 22:12 ` Timur Tabi
2010-05-20 8:28 ` Wolfgang Denk
2010-05-20 11:44 ` Timur Tabi
2010-05-25 16:07 ` Timur Tabi
2010-05-25 17:50 ` Wolfgang Denk
2010-05-25 18:01 ` Timur Tabi
2010-05-25 19:15 ` Wolfgang Denk
2010-05-25 19:28 ` Timur Tabi
2010-05-25 22:11 ` Wolfgang Denk
2010-05-26 15:11 ` Timur Tabi
2010-05-26 16:11 ` Wolfgang Denk
2010-05-26 16:38 ` Timur Tabi
2010-05-26 17:23 ` Scott Wood
2010-05-26 17:56 ` Timur Tabi
2010-05-26 18:06 ` Scott Wood
2010-05-26 18:23 ` Timur Tabi
2010-05-26 19:14 ` Wolfgang Denk
2010-05-26 19:08 ` Wolfgang Denk
2010-05-20 13:34 ` Kumar Gala
2010-05-20 12:58 ` Timur Tabi
2010-05-17 11:25 ` [U-Boot] [PATCH 2/3] " Jerry Van Baren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BF12771.2050802@gmail.com \
--to=gvb.uboot@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox