From owner-freebsd-dtrace@FreeBSD.ORG Thu Oct 31 07:01:20 2013 Return-Path: Delivered-To: dtrace@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4E53F931; Thu, 31 Oct 2013 07:01:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4F48F246D; Thu, 31 Oct 2013 07:01:18 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA14879; Thu, 31 Oct 2013 09:01:17 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VbmFp-000E1Q-99; Thu, 31 Oct 2013 09:01:17 +0200 Message-ID: <52720017.3060809@FreeBSD.org> Date: Thu, 31 Oct 2013 09:00:39 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Mark Johnston Subject: Re: "unstable" sdt probes References: <5268F461.7080504@FreeBSD.org> <20131024161620.GA1710@charmander> <526A9CB5.2050207@FreeBSD.org> <20131026180643.GA98676@raichu> <527026B3.2070309@FreeBSD.org> <20131031035523.GD9355@raichu> In-Reply-To: <20131031035523.GD9355@raichu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtrace@FreeBSD.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 07:01:20 -0000 on 31/10/2013 05:55 Mark Johnston said the following: > On Tue, Oct 29, 2013 at 11:20:51PM +0200, Andriy Gapon wrote: >> on 26/10/2013 21:06 Mark Johnston said the following: >>> The patch here is what I had in mind: >>> http://people.freebsd.org/~markj/patches/zfs_probes.diff >>> >>> I've only compile-tested it, but it should create illumos-compatible ZFS >>> probes without changing any ZFS code, assuming I understand exactly how >>> they're creating/naming probes. :) >> >> The simplicity and straightforwardness of your patch is very seducing! :-) >> I think that you missed sys/cddl/compat/opensolaris/sys/sdt.h, but that's a very >> a minor issue that is trivial to fix. > > Oops. I didn't even know that file existed. :) > >> >> I had something a little bit more elaborate on my mind. Something that would >> allow DTRACE_PROBE macros to work without providing any additional code per each >> probe. And also something that would make DTRACE_PROBE macros appealing to use >> in the FreeBSD code proper. > > Those macros don't address the problem of setting argument types though. I think nothing should prevent just explicitly using SDT_PROBE_ARGTYPE for probes defined via DTRACE_PROBE. If we want the types, that is. > We could do what illumos does, i.e. have a single giant table in > sdt_subr.c, but IMHO the SDT macros are more flexible. They let you > create and modify probes in a kernel module without recompiling the > kernel and rebooting, which something I've found handy in the past. Additionally, I think that what SDT_PROBE_ARGTYPE does can also be done directly in DTRACE_PROBE, because type information is provided to it. > For the purpose of creating unstable providers or quick debugging, I > guess it's ok to not define argument types, so I don't object to the > DTRACE_PROBE interface itself, but it'd be nice to avoid having both > SDT_* calls and DTRACE_* calls all over the tree. That'd be confusing. I agree.. The current status quo would be SDT_* in the FreeBSD proper code and DTRACE_* in the code with Solaris/illumos origins. >> So, I got some time to hack on this and here is a result: >> http://people.freebsd.org/~avg/dtrace-probe-macros.diff >> This change depends upon another change that I've just posted. > > Huh, for some reason I thought that DATA_SET() didn't work properly in a > function body. I remember trying something similar when I changed sdt to > use linker sets, and giving up because of some related problems, but I > don't remember exactly why. If it works, then I guess it's ok Seems to work just fine. DATA_SET just places an address of a global or static object into a linker set as far as I can see. > so long as > the sdt code handles duplicate entries in the probe set. :) Where would those comes from? Do we expect that there could be more than one SDT probe calls with the same name? But even if yes, I think that duplicates should be fine as long as they are exact duplicates. >> So, no surprise that I feel preference for my change, but I think that your >> change has certain advantage as well (esp. brevity and clarity). >> >> What do you think? > > The patch looks ok to me, but I can see that it won't apply to head/ - I > think it'll need at least r257152 and r254468. Yeah, I need to update my tree and rebase the patch. Thank you for the review! -- Andriy Gapon