[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.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org marcus@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Re: proxy memory objects patch, Marcus Brinkmann, 2002/12/03