[PATCH 10/10] fdtdump: add a debug mode

[Mike Frysinger]

On Monday 15 April 2013 01:12:06 David Gibson wrote:
> On Wed, Apr 10, 2013 at 02:29:15PM -0400, Mike Frysinger wrote:
> > -static void dump_blob(void *blob)
> > +static const char *tagname(uint32_t tag)
> >  {
> > +	static const char * const names[] = {
> > +#define TN(t) [t] #t
> > +		TN(FDT_BEGIN_NODE),
> > +		TN(FDT_END_NODE),
> > +		TN(FDT_PROP),
> > +		TN(FDT_NOP),
> > +		TN(FDT_END),
> > +#undef TN
> > +	};
> > +	if (tag < ARRAY_SIZE(names))
> > +		if (names[tag])
> > +			return names[tag];
> > +	return "???";
> 
> Better to return NULL here, I think.  That way a caller can easily
> check and print the numeric value instead.
> 
> Or you could construct a string with the number.  It would leak
> memory, obviously, but in a short-run program like this, it doesn't
> really matter.

if this were a general func (like in util.c or something), i'd agree with you.  
but the only consumer also prints out the #, so it'd be redundant:
        dprintf("%04zx: tag: 0x%08x (%s)\n",
                (uintptr_t)p - blob_off - 4, tag, tagname(tag));

the output looks like:
	// 350c: tag: 0x00000003 (FDT_PROP)

if it was an unknown value, it'd look like:
	// 350c: tag: 0x0000a123 (???)

> > +#define dprintf(fmt, args...) \
> > +	do { if (debug) printf("// " fmt, ## args); } while (0)
> 
> I'd prefer a different function (well, macro) name.  I tend to use
> "dprintf" for debug print functions in the sense of debugging for the
> program they're in, whereas in this case it's for the debug mode which
> is (primarily) for debugging other programs.

dumpf() ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20130415/e6d7c39f/attachment.sig>