bug-hurd
[Top][All Lists]
Advanced

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

Re: [PATCH] proxy memory object


From: Roland McGrath
Subject: Re: [PATCH] proxy memory object
Date: Sun, 12 Jun 2005 19:07:52 -0700 (PDT)

> There is something funky about the arrays.  I originally wanted to use
> "^array[]", but that was a loser.

What was the problem?  I haven't played with ^array[], but I know about
out-of-line parameters generally in the kernel.  The server stub gets
passed a vm_map_copy_t (cast to io_buf_ptr_t, i.e. char *) when the
parameter is out of line.You have to use vm_map_copyout on kernel_map to
look at the contents.

> The patch is tested and seems to work just fine for a single memory
> object, where offset and start are 0 and len is ~0.

store_map (or store type map hooks) could use this to fabricate a memory
object for a partitoin or remap store.  That would test some useful cases
with offsets and limits.  I really think at least some elementary tests of
the nontrivial arguments should be tested before it goes in.

Hmm, it looks like you haven't implemented that stuff at all, not just not
tested it.  I am a little dubious about putting in the RPC with all those
args when they aren't implemented.  I suppose there won't be many users to
change if the signature winds up changing.

> There will another patch follow up for the Hurd to make use of this in
> io_map.  I think it is a good idea to use proxy objects for both read
> and write memory objects, and not to give out the real memory object,
> ever, ever.  The reason is that this separates the reference counts,
> which is important for tmpfs and shared memory.  

That sounds fine to me.  

> However, we could also override this for tmpfs specifically, and use the
> real memory objects for the write object.  That would be a small
> optimization.

I wouldn't bother.


Thanks,
Roland




reply via email to

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