From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/6] ARM: zImage: Allow the appending of a device tree binary
Date: Wed, 14 Sep 2011 17:10:20 +0100 [thread overview]
Message-ID: <20110914161020.GH2104@arm.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1109141056150.20358@xanadu.home>
On Wed, Sep 14, 2011 at 11:10:44AM -0400, Nicolas Pitre wrote:
> On Wed, 14 Sep 2011, Dave Martin wrote:
>
> > On Wed, Sep 14, 2011 at 10:04:28AM -0400, Nicolas Pitre wrote:
> > > On Wed, 14 Sep 2011, Dave Martin wrote:
> > >
[...]
> > > > Do we worry that garbage in memory after the zImage might match this
> > > > magic number?
> > > >
> > > > For example, if an ordinary userspace program allocates a huge number
> > > > of pages and fills them with bogus device tree headers, is there a chance
> > > > that the those headers could remain in memory across a reboot?
> > >
> > > In theory this _could_ be possible. However I don't expect this feature
> > > to be enabled if you are not going to actually use it, especially in a
> > > production setup. If you are not appending a DTB to your kernel then
> > > there is simply no point keeping this config option set (normally you
> > > should use this option only because you have no other choices).
> >
> > That seems reasonable.
> >
> > Should we document this recommendation, in the Kconfig help or
> > Documentation/?
>
> I'll add some scary wording to the help text, and make it depend on
> EXPERIMENTAL as well. I prefer not to impose some expectations on the
> zImage layout for this even if not in use, like being stuck with an
> offset that we'll always have to guard against corruption due to people
> blindly scripting the zImage poking you suggested even when it is not
> needed.
>
> People will find ways to screw it up if they really want to anyway. So
> I'd lean towards keeping this simple and not create any legacy around
> this hopefully temporary accommodation feature.
Yeah, sure -- I think documentating it is enough for now.
And I agree we don't really want to reinvent the rdev nastiness for zImages...
Cheers
---Dave
next prev parent reply other threads:[~2011-09-14 16:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-14 5:41 [PATCH 0/6] zImage improvements with DTB append and ATAG compatibility Nicolas Pitre
2011-09-14 5:41 ` [PATCH 1/6] ARM: zImage: ensure it is always a multiple of 64 bits in size Nicolas Pitre
2011-09-14 5:41 ` [PATCH 2/6] ARM: zImage: Allow the appending of a device tree binary Nicolas Pitre
2011-09-14 13:32 ` Dave Martin
2011-09-14 14:04 ` Nicolas Pitre
2011-09-14 14:20 ` Dave Martin
2011-09-14 15:10 ` Nicolas Pitre
2011-09-14 16:10 ` Dave Martin [this message]
2011-09-14 5:41 ` [PATCH 3/6] ARM: zImage: make sure appended DTB doesn't get overwritten by kernel .bss Nicolas Pitre
2011-09-14 5:41 ` [PATCH 4/6] ARM: zImage: gather some string functions into string.c Nicolas Pitre
2011-09-14 13:13 ` Dave Martin
2011-09-14 13:45 ` Nicolas Pitre
2011-09-14 14:23 ` Dave Martin
2011-09-14 14:43 ` Nicolas Pitre
2011-09-14 5:41 ` [PATCH 5/6] ARM: zImage: allow supplementing appended DTB with traditional ATAG data Nicolas Pitre
2011-09-14 5:41 ` [PATCH 6/6] ARM: zImage: prevent constant copy+rebuild of lib1funcs.S Nicolas Pitre
2011-09-16 3:58 ` Stephen Boyd
2011-09-16 4:48 ` Nicolas Pitre
2011-09-16 7:15 ` Russell King - ARM Linux
2011-09-16 17:20 ` Stephen Boyd
2011-09-14 8:54 ` [PATCH 0/6] zImage improvements with DTB append and ATAG compatibility Shawn Guo
2011-09-14 13:19 ` Dave Martin
2011-09-14 15:26 ` Thomas Abraham
2011-09-14 22:56 ` David Brown
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=20110914161020.GH2104@arm.com \
--to=dave.martin@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.