From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32041 invoked by alias); 5 Aug 2010 12:33:48 -0000 Received: (qmail 32034 invoked by uid 22791); 5 Aug 2010 12:33:47 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00,TVD_RCVD_SPACE_BRACKET X-Spam-Check-By: sourceware.org Received: from mail9.hitachi.co.jp (HELO mail9.hitachi.co.jp) (133.145.228.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Aug 2010 12:33:39 +0000 Received: from mlsv6.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id 9667F37C83; Thu, 5 Aug 2010 21:33:37 +0900 (JST) Received: from mfilter3.hitachi.co.jp by mlsv6.hitachi.co.jp (8.13.1/8.13.1) id o75CXb02013806; Thu, 5 Aug 2010 21:33:37 +0900 Received: from hitachi.com (mfbcchk2.hitachi.co.jp [10.201.6.151]) by mfilter3.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id o75CPNbI021513; Thu, 5 Aug 2010 21:33:37 +0900 Received: from vshuts2.hitachi.co.jp ([vshuts2.hitachi.co.jp [10.201.6.71]]) by mfbcchk2.hitachi.co.jp with RELAY id o75CXa0a006150 ; Thu, 5 Aug 2010 21:33:37 +0900 Received: from hsdlgw92.sdl.hitachi.co.jp (unknown [133.144.7.20]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id 55B2E8B0116; Thu, 5 Aug 2010 21:33:36 +0900 (JST) Received: from vgate2.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.13.1/3.7W06092911) id o75CXZM7005499; Thu, 5 Aug 2010 21:33:35 +0900 Received: from sdl99w.sdl.hitachi.co.jp ([133.144.14.250]) by vgate2.sdl.hitachi.co.jp (SAVSMTP 3.1.1.32) with SMTP id M2010080521333530765 ; Thu, 05 Aug 2010 21:33:35 +0900 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by sdl99w.sdl.hitachi.co.jp (Postfix) with ESMTP id 22C16125514; Thu, 5 Aug 2010 21:33:34 +0900 (JST) Message-ID: <4C5AAF9E.6020005@hitachi.com> Date: Thu, 05 Aug 2010 12:33:00 -0000 From: Masami Hiramatsu User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andi Kleen Cc: systemtap@sources.redhat.com, Satoshi Oshima Subject: Re: [RFC] SystemTap future direction References: <4C58F852.7030103@hitachi.com> <87iq3qem1i.fsf@basil.nowhere.org> In-Reply-To: <87iq3qem1i.fsf@basil.nowhere.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-FMFTCR: RANGEC X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q3/txt/msg00190.txt.bz2 Andi Kleen wrote: > Masami Hiramatsu writes: > >> As you may know (of course I Cc'd discussion on LKML), Ingo and >> Christoph said that (at least) uprobes (but also kprobes) should >> not support out-of-tree module. > > They don't necessarily have the last word on this. Last word would be > Linus. > >> This means that if we succeed to merge uprobes into kernel, >> SystemTap can't use uprobes itself. Even worse, if someone tries >> to remove kprobes' module support, that could shake the foundation >> of SystemTap. > > There are already kprobes modules in tree I believe, which > would be broken too. Sure, there are some kprobe examples and jprobe users in kernel tree. > Also traditionally patches that broke a widely used free software > out of tree module haven't been merged in the past. I hope so. >> At least, to add support kmodules to uprobes, I think we have two >> options, one is pushing systemtap itself and useful scripts into >> kernel tree, or the other is finding very useful use-case of *probes >> which requires out-of-tree module. (But the first one is hard because >> Linus hates C++, and systemtap is too huge to push into the kernel) > > One thing that might work is to move at least larger parts of the > systemtap kernel runtime library into the kernel tree and then have > a couple of example modules written in C that exercise all the > interfaces (and ideally do something useful in the process too) > > In principle even compiler generated modules could be (at least > partially used for this), but I suppose they would need > quite some cleanups. It might be easier to do this with handwritten > C. Yeah, should be :) Nowadays systemtap generated modules are very complicated, because of safeness. > Then make sure the compiler output mostly only uses these interfaces. > That is they would need to be useful higher level interfaces, not just an > thin abstraction layer. I suspect 100% coverage wouldn't be possible > and also the compiler also would use use some other interfaces, > but as long as those are widely used driver interfaces there's > usually no problem. > > Basically it's important to have testing coverage in the kernel > for everything that can be used by compiler output (minus guru mode) > > This would probably need significant work to clean the library > up for kernel coding style etc. I think some of the code > could be also a lot simplified, especially if there were some > minor changes in the main kernel for this That's one reason why I've started to push trace-kprobe into the kernel, which provides a standard interface set for getting registers, stacks, and memories. I hope finally it could be shared with systemtap modules. > (I still don't understand how one needs 1.6kLOC to find a task :) > > But you could start in staging with this, so it doesn't require > doing all that work outside mainline. > > I think this would also largely fix the problem that systemtap often > breaks with new kernel versions. > > For example one of things I really like in systemtap are the > easy histograms. So if there was a histogram library function > in the kernel I assume that could even find other users. > Now that's only a small part of the code, but there could be more > of this. Thanks for a good advice. :) It should be a good candidate to be included in the kernel. Thank you, > > -Andi > -- Masami HIRAMATSU 2nd Research Dept. Hitachi, Ltd., Systems Development Laboratory E-mail: masami.hiramatsu.pt@hitachi.com