On Wed, Apr 08, 2009 at 02:18:51PM +0200, Renzo Davoli wrote: >> > #endif >> > #ifdef PTRACE_SINGLEBLOCK >> > case PTRACE_SINGLEBLOCK: >> > #endif >> > #ifdef PTRACE_SYSEMU >> > case PTRACE_SYSEMU: >> > case PTRACE_SYSEMU_SINGLESTEP: >> > #endif >> > case PTRACE_SYSCALL: >> > case PTRACE_CONT: >> > return ptrace_resume(child, request, 0, data); >> >+/* statements added for PTRACE_VM management */ >> >+#ifdef PTRACE_VM >> >+ case PTRACE_VM: >> >+#ifdef PTRACE_VM_SINGLESTEP >> >+ case PTRACE_VM_SINGLESTEP: >> >+#endif >> >+#ifdef PTRACE_VM_SINGLEBLOCK >> >+ case PTRACE_VM_SINGLEBLOCK: >> >+#endif >> >+ return ptrace_resume(child, PTRACE_VM_TAGS_MAPPING(request), addr, >> >data); >> >+#endif >> >.... >> > >> >> Hmmm, I see your points. Thanks for your analysis. >> >The "resume tags" SYSCALL, SINGLESTEP/SINGLEBLOCK, CONT give to ptrace >the command to resume and indicate when ptrace must stop next time. >The VM_SKIPCALL, VM_SKIPEXIT tags refer to the current system call. >The two sets are independent, orthogonal.
I see. > >I may want to skip this system call and stop either at the next system call >or at the next block, instruction or never. >As usual, everything is possible with or without some tags, the difference >in in this case in terms of clearness of the interface. Yes, sure. > >If we'd provide only a PTRACE_VM call (namely a PTRACE_VM_SYSCALL) >to resume up to the next syscall it was not possible to use it >to implement a virtualized "ptrace". >The virtual ptrace call may need to stop the process after an instruction >or a block as it was requested to do so. >In this case the VM monitor should use PTRACE_SINGLE* without the >VM_SKIP* optimization (maybe faking the execution of a getpid >to skip a system call, like in the old times of User mode Linux). >For a similar reason PTRACE_SYSEMY_SINGLESTEP was added in the kernel. > >WHy we should make life harder to VM monitor designer? > >We could also have a unique PTRACE_VM tag and encode both >SYSCALL/SINGLESTEP/SINGLEBLOCK/BLOCK >and >SKIPCALL/SKIPEXIT >in different bits inside the addr field. > >Again, this is a trick to use just one tag. >It is a matter of values. >Efficiency is the meaning of this patch, so it is a conditio >sine qua non. >Apart from efficiency, what do we want most? >Clearness of interface design? >Back compatibility for very improbable cases? > >I bet on the former, usually it is an insurance for the future. This is almost exactly what I said in my first mail, I have no objection to your patch, I like it, I just wanted to try to find a balance. Anyway, I will test your patch tomorrow, and will send you more feedbacks soon. Thanks. -- Live like a child, think like the god. ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
