From: David Gibson <david@gibson.dropbear.id.au>
To: Jerry Van Baren <gvb.linuxppc.dev@gmail.com>
Cc: linuxppc-dev@ozlabs.org, Jon Loeliger <jdl@jdl.com>
Subject: Re: libfdt: More tests of NOP handling behaviour
Date: Wed, 20 Feb 2008 13:04:07 +1100 [thread overview]
Message-ID: <20080220020407.GC18944@localhost.localdomain> (raw)
In-Reply-To: <47BB7FDB.3050809@gmail.com>
On Tue, Feb 19, 2008 at 08:18:19PM -0500, Jerry Van Baren wrote:
> Jon Loeliger wrote:
> > So, like, the other day David Gibson mumbled:
> >> In light of the recently discovered bug with NOP handling, this adds
> >> some more testcases for NOP handling. Specifically, it adds a helper
> >> program which will add a NOP tag after every existing tag in a dtb,
> >> and runs the standard battery of tests over trees mangled in this way.
> >>
> >> For now, this does not add a NOP at the very beginning of the
> >> structure block. This causes problems for libfdt at present, because
> >> we assume in many places that the root node's BEGIN_NODE tag is at
> >> offset 0. I'm still contemplating what to do about this (with one
> >> option being simply to declare such dtbs invalid).
> >>
> >> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >
> > Applied.
> >
> > BTW, declaring DTBs with BEGIN_NODES not at offset 0
> > as invalid seems like a fine choice to me.
> >
> > jdl
>
> FWIIW, I vote ditto on declaring DTBs with BEGIN_NODES not at offset 0
> as invalid. The root being at offset 0 assumption is pretty well
> entrenched and I cannot think of any reason to change it that would be
> worth the effort.
Well, it's actually not that hard to deal with. I've already been
planning to add a helper function/macro which validates a node offset
(something currently open-coded in a whole bunch of places). It would
be fairly easy to make it skip over nops as well.
But, likewise I can think of no reason that NOPs before the root node
would be useful or likely to occur in practice.
--
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
next prev parent reply other threads:[~2008-02-20 2:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-18 5:09 libfdt: More tests of NOP handling behaviour David Gibson
2008-02-18 14:24 ` Jon Loeliger
2008-02-20 1:18 ` Jerry Van Baren
2008-02-20 2:04 ` David Gibson [this message]
2008-02-22 23:42 ` 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=20080220020407.GC18944@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=gvb.linuxppc.dev@gmail.com \
--cc=jdl@jdl.com \
--cc=linuxppc-dev@ozlabs.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.