[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: XIP (Rev. 2)
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).
- Fully COW'ed
- No code duplication
- Existing resources are reusable
- 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...
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
> > 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
Main Index |
Thread Index |