[Top][All Lists]

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

Re: proxy memory objects patch

From: Marcus Brinkmann
Subject: Re: proxy memory objects patch
Date: Tue, 3 Dec 2002 23:29:46 +0100
User-agent: Mutt/1.4i

On Tue, Dec 03, 2002 at 05:18:56PM -0500, Roland McGrath wrote:
> > One variant that seems feasible is to simply specify the protection that
> > should apply to all ranges in all objects:
> > 
> > create_proxy (..., memory_object_t object[], vm_prot_t maxprot,
> >               vm_size_t start[], vm_size_t end[]);
> I think that is fine, and keeps it simpler for users.  I can't think of a
> real-world use that would want different protections in different regions,
> and of course you can always do "layered" proxy creations to get that effect.

I agree.
> The crucial parameter you missed is the offset.  Each [start_i,end_i) in
> the result corresponds to object_i at some offset, which the caller must be
> able to specify arbitrarily.  It would be more consistent with other
> Mach interfaces for the args to be vm_offset_t start[], vm_size_t len[].

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.
> Also, it seems worthwhile to make it possible to have a hole.  Maybe you
> intended that but didn't say.  e.g. an object[i] that is MACH_PORT_NULL
> means a hole at start[i].

Well, I did say it:

"Note that you can specify MACH_PORT_NULL as a memobj if you want a hole."
> In general I don't think the kernel should do a lot of work to make the
> interface easier for the caller, but the other way around.  So special
> cases for the last element and so forth are questionable.  

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.


`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]