Date: Tue, 09 Feb 2010 11:17:47 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: Kostik Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r203696 - in head: lib/libc/sys sys/kern sys/sys Message-ID: <896B58E6-12EA-48AB-86C2-5BA9F0C59512@mac.com> In-Reply-To: <20100209184043.GV9991@deviant.kiev.zoral.com.ua> References: <201002090552.o195qZcD074581@svn.freebsd.org> <20100209095722.GQ9991@deviant.kiev.zoral.com.ua> <65DCE552-7EFD-48F2-85A4-EA0F1F0638EE@mac.com> <20100209184043.GV9991@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 9, 2010, at 10:40 AM, Kostik Belousov wrote: *snip* Action items: >>> - vmspace should be referenced by vmspace_acquire_ref() >>> - vm_map should be read-locked before iterating the map entries. *snip* >> We can always put the timestamp in the structure. *snip* >> (2) the tracing process can check the timestamp returned by each >> request and compare that with the return value of the >> PT_VM_TIMESTAMP and restart the iteration. *snip* > I agree that #2 looks preferably, except that I consider it more > convenient when libc syscall wrapper return value is 0/-1 instead > of -1/some data. This means that timestamp might be added to > the existing struct ptrace_vm_entry. Of course. When I said returned, I didn't mean returned as the return value from ptrace. I used return to convey origin and direction of the information flow (see also the first sentence of my response :-) I'll implement it and send a patch for review to avoid unnecessary repository churn... Thanks! -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?896B58E6-12EA-48AB-86C2-5BA9F0C59512>