Hello Pierre, On 09/12, Pierre Morel wrote: > > You are right, the functionality can be implemented with the system call. > But it means we have the overhead of a system call just to clear two bits, > the TIF_SYSCALL_TRACE and the PTS_SELF.
Yes. So you want to optimize the code for the (imho very exotic) functionality. And again, the overhead of a system call is nothing compared to the signal delivery. I bet this overhead won't be visible with any benchmark. > On the other hand we have an overhead of one single "if" inside > the handle_signal() function. What if everyone who wants to add the new functionality will add one single "if + code" to the core kernel just because he wants to add a very minor optimization for his needs? And you forgot about the maintaince overhead. You forgot that this extra "if" uglifies/complicates the code. This all is imho of course, and I'm not maintainer. But I promise I will argue against this change forever ;) > We can do the same with fork and ptrace, yes, but with a very big > overhead on each system call and this is why this patch is so usefull: > because with this patch you sit inside the thread when analysing it and > have a direct access to all data without the need of IPC, ptrace or any > task switch. > > I will provide a test program and plan to release a tracing tool based > on it. Yes please, this would be very nice. Please do not count me, but I'm afraid I am not alone who needs to really understand why this patch is useful. Oleg. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
