Re: [LIBFDT] Fixup byteswapping code

[David Gibson <david@gibson.dropbear.id.au>]

On Fri, Dec 08, 2006 at 05:09:37PM +1100, David Gibson wrote:
> 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:

And I just pushed up a batch of patches which cleans up the errorr
handling as suggested there.

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