On Thu, Dec 05, 2002 at 05:33:07AM -0500, Roland McGrath wrote:
> > Mmh, I was actually thinking of a hole as being anonymously allocated
> > memory, ie, zero filled.
>
> Oh, that's not what I was talking about. That's not a hole, it's an
> anonymous memory object. I guess that is the appropriat
> Mmh, I was actually thinking of a hole as being anonymously allocated
> memory, ie, zero filled.
Oh, that's not what I was talking about. That's not a hole, it's an
anonymous memory object. I guess that is the appropriate semantic to match
vm_map, as Thomas says. I suppose if you need a real
On Tue, Dec 03, 2002 at 08:29:20PM -0800, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > > 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
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> > 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_NUL
> 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
On Tue, Dec 03, 2002 at 11:29:46PM +0100, Marcus Brinkmann wrote:
> > 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
On Tue, Dec 03, 2002 at 05:18:56PM -0500, Roland McGrath wrote:
> > create_proxy (..., memory_object_t object[], vm_prot_t maxprot,
> > vm_size_t start[], vm_size_t end[]);
>
> The crucial parameter you missed is the offset. Each [start_i,end_i) in
> the result corresponds to object
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[], v
> 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
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> We have: memory objects, protection, linear ranges. Thomas suggested we
> need an array of linear ranges and you say we need an array of
> objects.
In my version, the interface would not have an array of linear ranges,
but only one. But since you n
On Wed, Nov 20, 2002 at 09:16:12PM -0500, Roland McGrath wrote:
> If you can implement the interface that takes many objects and ranges from
> each, please do that. The reason to want this is so that we can use it to
> compose proxy memory objects that span adjacent memory objects of logically
> c
On Wed, Nov 20, 2002 at 09:12:06PM -0500, Roland McGrath wrote:
> > here is my patch for proxy memory objects
>
> Yowza! Does it actually work?
Yes, it is tested. I wrote two programs: One calling io_map and mapping the
memobjrd for writing, which is basically an exploit. The other creates a
p
On Wed, Nov 20, 2002 at 09:16:12PM -0500, Roland McGrath wrote:
> If you can implement the interface that takes many objects and ranges from
> each, please do that. The reason to want this is so that we can use it to
> compose proxy memory objects that span adjacent memory objects of logically
> c
Roland McGrath <[EMAIL PROTECTED]> writes:
> > The nice thing here is that with this interface, we can fix it to use
> > the *right* (but much harder) implementation at any later date.
>
> Indeed. That's why I don't want vm_map to fail even when it can
> immediately tell that all access will fai
Roland McGrath <[EMAIL PROTECTED]> writes:
> If you can implement the interface that takes many objects and ranges from
> each, please do that. The reason to want this is so that we can use it to
> compose proxy memory objects that span adjacent memory objects of logically
> contiguous underlying
> The nice thing here is that with this interface, we can fix it to use
> the *right* (but much harder) implementation at any later date.
Indeed. That's why I don't want vm_map to fail even when it can
immediately tell that all access will fail, for example.
If you can implement the interface that takes many objects and ranges from
each, please do that. The reason to want this is so that we can use it to
compose proxy memory objects that span adjacent memory objects of logically
contiguous underlying objects like files and disks. That lets us use the
> here is my patch for proxy memory objects
Yowza! Does it actually work?
> There is a new file in vm/memory_object_proxy.c and a new interface in
> mach4.defs. I have added a couple of skip's in the !MACH_PCSAMPLE case,
> because I think reusing msgid's is bad mojo, but I am not sure if
> MACH
The implementation of memory_object_create_proxy should allow a proxy
object to be passed as the value of OBJECT, and dereference it, and
then make a proxy object with the minimum set of the two.
Note that if you add the range-restriction to this, the result will be
that proxy objects need to spe
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> There is a new file in vm/memory_object_proxy.c and a new interface in
> mach4.defs. I have added a couple of skip's in the !MACH_PCSAMPLE case,
> because I think reusing msgid's is bad mojo, but I am not sure if
> MACH_PCSAMPLE is something to worry
20 matches
Mail list logo
