From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [59.151.112.132] (helo=heian.cn.fujitsu.com) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZcS1b-0006qX-Th for linux-mtd@lists.infradead.org; Thu, 17 Sep 2015 05:46:28 +0000 Message-ID: <55FA5220.3070402@cn.fujitsu.com> Date: Thu, 17 Sep 2015 13:39:44 +0800 From: Dongsheng Yang MIME-Version: 1.0 To: Richard Weinberger , , CC: Subject: Re: [RFC PATCH 00/27] Introduce ubifs_dump in ubifs-utils References: <1439973572-12489-1-git-send-email-yangds.fnst@cn.fujitsu.com> <55F96F61.8040201@nod.at> In-Reply-To: <55F96F61.8040201@nod.at> Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 09/16/2015 09:32 PM, Richard Weinberger wrote: > Yang, > > Am 19.08.2015 um 10:39 schrieb Dongsheng Yang: >> Hi Atem, Richard and Brian, >> This patchset introduce a userspace tool named ubifs_dump >> to dump data from a ubi media. >> It will dump the areas in ubifs, such as super block, >> master, log, lpt and main. >> That's helpful for us to see what exactly written in >> media. >> the [1/patch] is a RESEND patch, it restructures the mtd-utils. >> Please Brian help to take a look at it. thanx a lot. :) >> >> NOTE: >> This patch set depends on a patch I sent out [ubifs: correct the size of nnode in memset] >> But you can get a full code at: >> https://github.com/yangdongsheng/mtd-utils.git ubifs_dump_v1 > > I'm looking/testing right now your patches. > Your tools is useful. I like the idea, maybe the can change the name to > "ubifs_dump_meta"? Do you have plans to extend it? Hi Richard, ubifs_dump_meta? Hmmm, but I also dump data nodes in it. Do you have some reason to rename it? Extend it? Of course, I would like to make it better and better. But the first step is making it in mtd-utils. > > I'm asking because I've started working on an ubifs.fsck/debugfs tool based on > some scripts and hacky other tools I wrote some time ago. > So, let's coordinate and avoid double work. Oh, sorry for sending my patch without any asking. I thought there is nobody caring about it. And what's more, I am planning to do a fsck.ubifs actually. Haha, so I think we can cooperate on it. Could you share more about your work so far? > > It's first feature is being able to extract all files from an UBIFS. > Scanning and identifying all UBIFS nodes, as your tool does, is a subset > of the needed functionality. As you sent patches first I'll happily rebase > my tool to your patches. Thanx a lot. :) > One of the major differences is that it will work without the UBI/UBIFS kernel > modules. You can use /dev/ubiXY or a plain nanddump. > I hope I can release the first version soon. Yea, sounds very interesting, although I am not sure how it can be implemented. Looking forward your release. Thanx Yang > > Thanks, > //richard > . >