[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <000e01c8a6aa$ce638960$6b2a9c20$@css.fujitsu.com>
Date: Fri, 25 Apr 2008 17:03:11 +0900
From: "Takashi Nishiie" <t-nishiie@...css.fujitsu.com>
To: <fox@...sp.demon.co.uk>, <bart.vanassche@...il.com>
Cc: <linux-kernel@...r.kernel.org>
Subject: RE: dtrace for linux
>> On Sun, Apr 20, 2008 at 1:17 AM, <fox@...sp.demon.co.uk> wrote:
>>>
>>> I would like to announce that I am working on dtrace for Linux.
>>> I have the userland dtrace binary compiled, along with the first
>>> pre-pre-alpha dtracedrv.ko module loaded into my kernel.
>>
>> This is great news. How will this dtrace implementation differ from
>> SystemTap (http://sourceware.org/systemtap/) ?
>>
>> Bart.
>>
>>
>
>Hello Bart,
>
>
>I dont know systemtap all that well, other than what i have
>read on the net and browsed in the source. systemtap is similar,
>but dtrace provides a high level functional language (D) and
>a set of methodologies and scripts which mean learning/training
>will make it easier to use.
Hello,
SystemTAP is the tool developed in order to do the same thing
as Dtrace. When development of SystemTAP started, Dtrace was not
able to be used with restriction by the license at linux. The
difference in both SystemTAP and Dtrace is produced by avoiding
being based on mounting peculiar to linux, and a license.
By the way, aren't any ideas found in order to mitigate the
load when acquiring trace? If load when having taken trace as
for LTTng as for SystemTAP is too heavy, I feel. For example,
it is desirable that trace with lighter load can be taken by the
limiting conditions of obtaining the trace result only for
several seconds until panic occurs.
Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists