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
