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 [EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/ _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
