Re: XIP (Rev. 2)

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

On Tue, Nov 09, 2010 at 09:24:06PM +0200, Antti Kantee wrote:
> On Tue Nov 09 2010 at 12:47:11 -0600, David Young wrote:
> > On Tue, Nov 09, 2010 at 04:31:22PM +0200, Antti Kantee wrote:
> > > A big problem with the XIP thread is that it is simply not palatable.
> > > It takes a lot of commitment just to read the thread, not to mention
> > > putting out a sensible review comments like e.g. Chuq and Matt have done.
> > > The issue is complex and the code involved is even more so.  However,
> > > that is no excuse for a confusing presentation.  It seems like hardly
> > > anyone can follow what is going on, and usually that signals that the
> > > audience is not the root of the problem.
> > 
> > If the conversation's leading participants adopt the rule that they may
> > not introduce a new term ("pager ops") or symbol ("pgo_fault") to the
> > discussion until a manual page describes it, then we will gain some
> > useful kernel-internals documentation, and the conversation will be more
> > accessible. :-)
> 
> Those concepts are carefully documented, if nowhere else, at least in
> the uvm dissertation.  Basically a pager is involved in moving things
> between memory and whatever the va is backed with (swap, a file system,
> "ubc", ...).  There's pgo_get which pages data from the backing storage
> to memory (*) and pgo_put which does the opposite.  Additionally there's
> pgo_fault which is like pgo_get except the interface allows the method
> a little more freedom in how it handles the operation.  ... but i don't
> know if that's a helpful explanation unless you are familiar with pagers,
> which is why it is very difficult to produce succint documentation on
> the subject -- everyone learns to understand it a little differently.
> 
> *) obviously in the case of XIP "to" is a matter of mapping instead
> of transferring
> 
> But, the problem was not so much the use of terminology as it was the
> lack of any clear focus on the direction.  I can't form a clear mental
> image of the project, although admittedly I didn't even finish reading
> the earlier thread yet.
> 
> Like gimpy said, the diff is a big piece to swallow since it's so full
> of "unrelated" parts:
> 
> 1) man pages
> 2) new drivers
> 3) vm
> 4) vnode pager
> 5) MD collateral

My XIP honors abstraction.  It has little impact against upper
layers (vnode, filesystem, etc.).

XIP is built on top of physical segment layer (physical RAM pages
or device pages).  There things are horribly abstracted.  This is
what you call "unrelated" changes, uvm_page.c.

> 
> Then again, it's missing pieces (what's pmap_common.c?  and isn't that
> a slight oxymoron ?)
> 
> The diff would be much more browsable if it was separated into pieces
> and the man pages attached as rendered versions.  Although reading the
> diff is quicker than reading the previous thread ;)
> 
> A radically different implementation at this stage seems feasible only
> if there is strong reason for that based on another actually existing
> implementation (in another OS, of course).
> 
> Beauty issues aside, can we have a summary of the current implementation
> of XIP from a functional perspective, i.e. what works and what doesn't.
> That's what users care about ...

Read-only XIP memory disk works
Read-only FlashROM memory disk works
Write doesn't work

That's all.  This is documented in man pages.  I'll put rendered ones next.