> 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 _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
