At Sun, 12 Jun 2005 19:07:52 -0700 (PDT), Roland McGrath wrote: > > > There is something funky about the arrays. I originally wanted to use > > "^array[]", but that was a loser. > > What was the problem?
I didn't see the right data. > 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. Ah, ok. That must have been it, I just tried to use the pointer directly. Do you think it is worth to go through this trouble here? > > 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. Right. > 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. Yeah, all-right, but I would be happy if you could make up your mind on this. Last time this came up I posted a complete, working patch with just the args I needed for the simple case. At that time, Thomas asked me to modify the prototype to allow for a range restriction, and you asked me to also take into account multiple objects. There are three options here, and I don't really care which one we go for: 1. Apply my original patch from Nov 20 2002 (!!!). But why didn't we do it 2-and-a-half years ago when I already made clear that I won't implement the generic case fully? 2. Apply my new patch, with the generic interface. 3. Somebody commits _now_ to implement the generic case within a reasonably short time frame. I won't do it. This is, for me, all about fixing a glaring security hole, which has existed ever since. Well, since some time it is also about allowing for tmpfs and shared memory, but that is a side-issue. Thanks, Marcus _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
