Re: [RESEND PATCH v3 2/7] Add utilfdt for common functions

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

On Mon, Sep 19, 2011 at 08:54:02PM -0700, Simon Glass wrote:
> Hi David,

[snip]
> > Building a shared library out of this is complete overkill.  In fact,
> > so is building a .a of it.  This is not an exported library for
> > general use, but just an internal mini-"library" for use by the fdtget
> > and fdtput functions.  Just have them both link with utilfdt.o.
> 
> I guess I misunderstood your comment on this patch in v2, referring I
> thought to the function to read an fdt:

Yeah, sorry, I don't think I was very clear.

> > Yes, you'll need to fix that for a general library version.  It
> > should indeed return an error rather than dying.
> 
> I took that to me it should be in a library, and of course it couldn't
> be in libfdt due to the OS use...

Well, I've contemplated adding such things to libfdt.  It should be
workable as long as they're in a separate module which could be left
out when building for constrained environments.  But I'd be much
pickier about the details of the interface in that case, I don't think
we're quite ready for this yet.

> It is used by the tests, ftdump, fdtget and fdtput. I didn't really
> want the tests to have to have -I.. and linking ../utilfdt.o.
> 
> So should I just make in an object file in the root that everything
> except dtc links with?

You know what.  On further consideration, just drop it into util.c,
which already has random handy but not exported functions shared
between dtc and ftdump.

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