Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750901AbWISQP2 (ORCPT ); Tue, 19 Sep 2006 12:15:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750905AbWISQP2 (ORCPT ); Tue, 19 Sep 2006 12:15:28 -0400 Received: from smtp-out.google.com ([216.239.33.17]:23453 "EHLO smtp-out.google.com") by vger.kernel.org with ESMTP id S1750885AbWISQP1 (ORCPT ); Tue, 19 Sep 2006 12:15:27 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:user-agent: x-accept-language:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; b=c8guur0E/TlTatm5+/66176HmiArjh+6ru71VyCEmONgQavlodS/D6UHrB+3fFWRY vYiREvUNWb/0cEHbD3PfQ== Message-ID: <4510175B.7000200@google.com> Date: Tue, 19 Sep 2006 09:14:19 -0700 From: Martin Bligh User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051011) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vara Prasad CC: Ingo Molnar , Mathieu Desnoyers , "Frank Ch. Eigler" , Paul Mundt , linux-kernel , Jes Sorensen , Andrew Morton , Tom Zanussi , Richard J Moore , Michel Dagenais , Christoph Hellwig , Greg Kroah-Hartman , Thomas Gleixner , William Cohen , ltt-dev@shafik.org, systemtap@sources.redhat.com, Alan Cox Subject: Re: [PATCH] Linux Kernel Markers References: <20060918234502.GA197@Krystal> <20060919081124.GA30394@elte.hu> <451008AC.6030006@google.com> <45101598.7050309@us.ibm.com> In-Reply-To: <45101598.7050309@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1796 Lines: 38 > It is an interesting idea but there appears to be following hard issues > (some of which you have already listed) i am not able to see how we can > overcome them > > 1) We are going to have a duplicate of the whole function which means > any significant changes in the original function needs to be done on the > copy as well, you think maintainers would like this double work idea. No, no ... the duplicate function isn't duplicated source code, only object code. Either a config option via the markup macros that we've been discussing, or something I hack up on the fly to debug a problem dynamically. In terms of how the debugging-type source code is kept, it's no different than something like systemtap or LTT (either would work, and a normal diff could be used to keep out of tree stuff), it's just how it hooks in is different to kprobes. > 2) Inline functions is often the place where we need a fast path to > overcome the current kprobes overhead. You can still instrument inline functions, you just need to hook all the callers, not the inline itself. > 3) As you said it is not trivial across all the platforms to do a switch > to the instrumented function from the original during the execution. > This problem is similar to the issue we are dealing with djprobes. If we just freeze all kernel operations for a split second whilst we do this, does it matter? Or even if we don't ... there's a brief race where some calls are traced, and some are not ... does that even matter? Doesn't seem like most usages would care. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/