Re: XIP (Rev. 2)

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

I think your approach descibed here is something intermediate
between my "generic" one and a "dedicated" one - which we talked
privately long time ago - that designing a dedicated ROM format,
hooks map with XIP execution in exec handler, etc.

I chose "generic" approach, because I wanted to

- Avoid unexpected problems (I didn't know what I didn't know), and
- Avoid creating dedicated filesystem and its tools
- Honor abstraction
- Avoid code duplication
- Optimize later

So mine reuses all the existing code path of filesystem, vnode
pager (except the genfs_getpages_xip).

Pros:
- Fully COW'ed
- No code duplication
- Existing resources are reusable

Cons:
- Slow
- Inefficient (use normal sized TLBs)
- Too generic; redefine some fundamental assumptions of Unix

I admit this is hard to understand.  But it's not solely my fault.
XIP is an odd concept by nature...

Masao

On Tue, Nov 09, 2010 at 09:19:15AM -0800, Matt Thomas wrote:
> 
> On Nov 9, 2010, at 9:06 AM, Masao Uebayashi wrote:
> 
> > On Tue, Nov 09, 2010 at 08:39:16AM -0800, Matt Thomas wrote:
> >> 
> >> On Nov 8, 2010, at 11:25 PM, Masao Uebayashi wrote:
> >> 
> >>>   http://uebayasi.dyndns.org/~uebayasi/tmp/uebayasi-xip-20101109.txt
> >> 
> >> Besides the churn (and there is a lot of it), I think my fundamental
> >> problem with this incarnation of XIP is that it took a wrong approach.
> >> It has tried to fit itself under uvm_vnodeops and I think that's a
> >> fatal flaw by requiring invasive changes to contort to that decision.
> >> 
> >> Instead, XIP should have its own pager ops uvm_xipops and vnodes should
> >> be set to use that in vnalloc/insmntque which is easily done since you 
> >> can just check for MNT_XIP in the passed mount point.
> > 
> > I understand having a separate pager would work too.  If you go
> > that route, you have to give up COW.  The two layered amap/uobj is
> > the fundamental design of UVM.
> 
> You don't have to give up COW, you have to deal with it.  And those
> changes will be far less pervasive than the changes you've had to make.
> 
> > I'd also point out that pgo_fault() is prepaired only for *special*
> > purposes.  My plan is to rewrite those backends to use pgo_get().
> > Then use single pmap_enter().
> 
> And XIP isn't special?  But I disagree that pgo_fault is only for
> those purposes.  It could be used for more but that hasn't been
> needed.
> 
> > Both of yours and mine are possible, and there're pros and cons.
> 
> That's true.  

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635