Re: [PATCH] mtd: allow mtd and jffs2 when ARCH=um

[Rob Landley <rob@landley.net>]

On Tuesday 14 December 2010 14:01:33 Artem Bityutskiy wrote:
> > > Instead, you should solve this problem in UML code. I do not know how,
> > > but may be you can add readb/writeb there which actually do nothing or
> > > print a scary warning, or do BUG(), and let things which use them just
> > > fail run-time.
> >
> > Something like this could work, but it would be error-prone for anyone
> > else who attempts using iomem-requiring drivers on uml. Instead of
> > getting obvious compile failures we'd have broken drivers that BUG() or
> > emit scary warnings. That doesn't seem to me like an improvement.
>
> This problem does not seem to be mtd-specific, right? So my point was
> that it would be nicer to come up with a general solution.

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.

It would be really nice to have either the loopback driver or jffs2 be able to 
fake the mtd thing with some kind of "granularity=262144" option to let it 
know "you're not on flash right now, but the flash you'll eventually be on is 
X".  This might require padding the image at the beginning and being mounted 
with an offset if the filesystem doesn't start at the beginning of an erase 
block when copied to the final hardware, but losetup already supports offsets.

What any of this has to do with UML is an open question.  I don't want to 
require UML to loopback mount a jffs2 image, I want to be able to do it from my 
host.  From my perspective, you're solving the wrong problem.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.