From: David Gibson <david@gibson.dropbear.id.au>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [LIBFDT] Fixup byteswapping code
Date: Fri, 8 Dec 2006 17:09:37 +1100 [thread overview]
Message-ID: <20061208060937.GB32700@localhost.localdomain> (raw)
In-Reply-To: <528646bc0612040655j60a7e93emb151ddd55e6db984@mail.gmail.com>
On Mon, Dec 04, 2006 at 07:55:59AM -0700, Grant Likely wrote:
> On 12/4/06, David Gibson <david@gibson.dropbear.id.au> wrote:
> > I do have one idea for better error handling: I'd like to put in
> > something defined in the the libfdt_env.h (which is designed to be
> > replaced when libfdt is compiled in different environments) to report
> > an error. That would be invoked every time a libfdt function exits
> > with an error - I would envisage it calling through to a user supplied
> > function pointer.
> >
> > In many practical situations, I think most libfdt errors would be the
> > result of something unrecoverable problem (such as a corrupted device
> > tree blob), the callback could just print an error (by whatever means
> > is appropritate for the environment) and bail out, avoiding the need
> > for checking return values. At least for the "serious" errors
> > (BADMAGIC, BADSTRUCTURE and so forth). NOTFOUND (and maybe TRUNCATED)
> > would need to be passed back as a return value still, since that can
> > certainly occur in a legitimate test.
>
> Yeah, that's not a bad idea. That way the complexity of making it
> thread safe is left with the execution environment, not with libfdt,
> and it still leaves the possibility of application code retrieving the
> error code if it is interested.... Still not ideal, but of the
> options presented, I like this one best.
Actually, I had some more thought about this. There really aren't
that many functions returning pointers there's:
_fdt_getprop() (which I'm thinking about renaming and making
externally visible)
fdt_getprop()
fdt_create()
fdt_open_into()
fdt_pack()
fdt_move()
fdt_pack() doesn't actually move anything, so it could just return an
error code instead.
fdt_open_into(), fdt_create() and fdt_move() all return a device tree
at the beginning of the given buffer. So, they too could return just
an error code instead. That's a little ugly from the user's POV
because they'd have to manually cast the (void *) buffer pointer into
(struct fdt_header *). However, I was thinking in any case about
changing all the fdt parameters to just be void * and doing the casts
inside the library, which removes that problem. In addition it
re-emphasises the idea of the blob as a blob, whose internal structure
the caller need not understand.
That leaves _fdt_getprop() and fdt_getprop(). Those both take an int
pointer to return the length. So, I was thinking they could instead
return NULL for errors, and store the detailed error code in the
length parameter: both structure offsets and lengths have the nice
property that negative values are "naturally" out-of-bounds.
What do you think?
--
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:[~2006-12-08 6:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-02 8:45 [LIBFDT] Fixup byteswapping code Grant Likely
2006-12-02 8:45 ` [LIBFDT] Add .dtb files to .gitignore Grant Likely
2006-12-02 9:30 ` Segher Boessenkool
2006-12-04 0:19 ` David Gibson
2006-12-04 1:53 ` [LIBFDT] Fixup byteswapping code David Gibson
2006-12-04 5:18 ` Grant Likely
2006-12-04 5:52 ` David Gibson
2006-12-04 6:33 ` Grant Likely
2006-12-04 7:16 ` David Gibson
2006-12-04 14:55 ` Grant Likely
2006-12-08 6:09 ` David Gibson [this message]
2006-12-15 4:15 ` David Gibson
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=20061208060937.GB32700@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=grant.likely@secretlab.ca \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).