[PATCH][MTD] mtdpart.c: allow other drivers to get physical address of partition

[Jörn Engel]

I ignored this in my previous reply.

On Tue, 31 July 2007 12:55:23 -0700, Jared Hulbert wrote:
> 
> Like what? :)  I'm all for the kinds of ideas that Jörn and others are
> tossing about as replacement for better XIP awareness in the MTD.  I'm
> just not catching the vision enough to start coding.

Neither am I.  My missing puzzle piece is how to zap all page mappings
for the chip in question.  Maybe the fs/vm meeting at lce will clear
things up.

> One of the major problems with working on Flash based XIP stuff for
> the kernel is that there are no mergeable filesystems to use the any
> frameworks we develop.  The VM still doesn't handle this correctly,
> point() needs work.  There are a lot of fronts to attack.  What I was
> hoping for was to get the minimum requirements for me to get AXFS
> supported by the kernel, then to come back and provide more educated
> and correct interfaces in the vm and mtd layers.  That way we could
> have the example of how it is being done in AXFS to frame the
> discussion and give it more urgency.  I'm beginning to think this
> isn't the correct approach.

If I started working on this I'd probably want AXFS on one partition and
JFFS2 on another.  Being able to write to JFFS2 while reading XIP files
from AXFS without corruptions is the major milestone.  When that works
we can think about the other 90% of having both write support and XIP in
the same filesystem.

How serious is Intel about merging AXFS in mainline, btw?

> If that won't work then can I propose a face to face meeting with
> interested parties like a mini XIP summit or something.  There are
> those that are informed and interested enough to want this done right
> and have a definate opinion as to what is right and wrong here, but
> that don't have time to develop this.  I on the other hand have the
> ability to get this coded up but am more in the dark as to the
> 'correct' way to do this.  If we could sit down and sketch out how to
> go about this I think it would be very productive.  Potential
> interested parties could include me, Woodhouse, Engel, and Otte.
> Anybody else come to mind?

Maybe another vm person or two.  The vm part is the critical missing
piece and needs all the brainpower we can get.

Jörn

-- 
Joern's library part 1:
http://lwn.net/Articles/2.6-kernel-api/