linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).