Re: proxy memory objects patch

[Roland McGrath]

> I was thinking that they are all appended linearly starting at 0, so the
> offset is implied by the length of the previous objects.  If you want to
> create a hole, you must specify this explicitely by adding a hole into the
> list (see below).  This makes it simpler because there is no question about
> overlapping etc.

Oh, I see.  I was reading start and end as both being locations in the
result memobj.  You are saying that start is the offset in the underlying
memobj, and "end" implies the length of the run in the result memobj.

> "Note that you can specify MACH_PORT_NULL as a memobj if you want a hole."

Oops, overlooked it.

> I think it is important to make the last element open ended, because of the
> possibility of resizing files.  If a file is grown, I think you should be
> able to map the grown area from the proxy object you already got without
> calling io_map again.  This keeps a read only proxy object for a file in
> sync with the writable object if it changes size.  But maybe I am thinking
> wrong about resizing of memory objects, I never really looked into the
> extensions you did to make it possible.

Memory objects don't really have "size" in the sense that a user can tell.
You ask for a page and it's there or it's not.  So a proxy object's address
space can all map to another object, regardless of how much of the space
could really be accessed if you tried.  It doesn't need to be any
special-case feature, the final range just maps the whole rest of the final
object in the given length.  For convenience, we should make it that a
length off the end of the result object is silently truncated, so you can
just specify -1.