tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: XIP (Rev. 2)

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

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 ...

Home | Main Index | Thread Index | Old Index