Re: [PATCH 06/10] fdtdump: add a --scan option

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

[-- Attachment #1.1: Type: text/plain, Size: 2777 bytes --]

On Thu, Apr 11, 2013 at 06:44:20PM -0400, Mike Frysinger wrote:
> On Thursday 11 April 2013 00:11:30 David Gibson wrote:
> > On Wed, Apr 10, 2013 at 02:29:11PM -0400, Mike Frysinger wrote:
> > > Often times, fdts get embedded in other larger files.  Rather than force
> > > people to `dd` the blob out themselves, make the fdtdump file smarter.
> > > 
> > > It can now scan the blob looking for the fdt magic.  Once locate, it does
> > > a little validation on the main struct to make sure we didn't hit random
> > > binary data.
> > 
> > Hrm.  I have mixed feelings about this.  The scanning functionality is
> > certainly useful.  But on the other hand, fdtdump is not supposed to
> > be a general use tool.  It's basically a debugging aid: a quick and
> > dirty independent implementation of a dtb dump, for checking that dtc
> > is producing sane output.  The preferred way to dump dtbs "for real"
> > is to use dtc -I dtb -O dts
> > 
> > I think the way I'd prefer to see this functionality would be to add a
> > new input format to dtc which is a little wrapper around the dtb input
> > format which does the scan.
> 
> that seems reasonable, but really my use case was: scan a big blob, find the 
> dtb embedded in there, then both decode and dump the offsets.  this was so i 
> could easily hack said big blob with a hexeditor and tweak a few
> keys.

Yeah, so when I got to your debug patch, I already started changing my
mind here.

> adding a new input format would satisfy the first part (locating the dtb), and 
> the fact that dtc already supports "-O dtb" is good as it'd allow me to run it 
> through fdtdump after the fact.  i can probably even chain them in a pipeline.
> 
> i'd still want the --debug option in fdtdump, but it sounds like that wouldn't 
> be against your desired goal for this utility ?
> 
> if that sounds good to you, i can rework things so that dtc gets a new "scan" 
> input format (guessing i don't need to name it "scan-dtb").  then we both 
> should be happy.

Actually, you've convinced me.  So for now, just go back to your
original approach and address the other more specific comments and
that should be fine.  When I made that suggestion I hadn't realised
what you were using this for.  Now that I have, I think it fits into
fdtdump as intended.

> on a related note, is there a reason these tools malloc & read in the whole 
> file into memory instead of just doing mmap() when possible ?

Some combination of simplicity and portability.  I've never really
thought about it much..

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss