[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTinaXvc=3r9gRNkSnttay-2yD9BDtXo0mOmMff0H@mail.gmail.com>
Date: Wed, 15 Dec 2010 09:18:33 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Jason Lunz <lunz@....org>
Cc: Rob Landley <rob@...dley.net>, dedekind1@...il.com,
richard -rw- weinberger <richard.weinberger@...il.com>,
Sam Ravnborg <sam@...nborg.org>,
David Woodhouse <dwmw2@...radead.org>,
atom ota <atomota@...epyhammer.com>,
user-mode-linux-devel@...ts.sourceforge.net,
Jeff Dike <jdike@...toit.com>,
lkml <linux-kernel@...r.kernel.org>,
linux-mtd@...ts.infradead.org
Subject: Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um
On Wed, Dec 15, 2010 at 02:19, Jason Lunz <lunz@....org> wrote:
> On Tue, Dec 14, 2010 at 06:49:02PM -0600, Rob Landley wrote:
>> The problem is that jffs2 is a filesystem, and thus something people would
>> really like to be able to loopback mount, but it's hardwired to assume it's
>> only ever stored on a certain type of hardware, and thus requies incestuous
>> knowledge of the erase granularity of the flash layer in order to function.
>
> I assume you can turn your jffs2 image file into a block dev using
> losetup, then turn the corresponding loop device into an mtd device
> using block2mtd, at which point you ought to be able to mount it with
> jffs2. I've never tried it.
And block2mtd is part of mtd, so you have to get mtd compiled first.
BTW, the patch I used in the past was less intrusive than yours.
I attached it, as I can't send it inline from here.
Note that it was against 2.6.31-rc4.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
View attachment "uml-mtd.diff" of type "text/x-patch" (3089 bytes)
Powered by blists - more mailing lists