From owner-freebsd-dtrace@FreeBSD.ORG Sat Oct 26 19:24:19 2013 Return-Path: Delivered-To: dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3D84C843 for ; Sat, 26 Oct 2013 19:24:19 +0000 (UTC) (envelope-from rm@joyent.com) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F0F4B2E75 for ; Sat, 26 Oct 2013 19:24:18 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id e16so2739898qcx.34 for ; Sat, 26 Oct 2013 12:24:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EFdkSuPnxx6arFVd2vdW1XXSU5yFUiwxNlMromtCn/w=; b=A3i9vOYebEsfU8AXa5IRfbcYolu93LygHpQUYyqsoKA+cbEP4Ul009bbtpyW6nNEmZ XfBDbYs1Feef50qR9zGAF8B3vMMXfx5ZHZukUPI8abKvzRj0aDY/cSFsbktKZiK+RIHe 53+AyrHi2NLVIGpTU/Dzjs7UEe+p6Kj++8Rmxn9SYwxoeQrZXmUr0/ZLt5EdIqo/HP8I iArrdLTy53KWDfYNvmctnPJmgiAg2z4OTOkm9I5MZtzawwYRcWAYZWNXudmugUaUMpAJ 648bt6Qpm8/Ow21U8yzHdQd0bVQp8W5Wh7jPZpfz3rzISF4FuPYq3RMK3rAjBP7/8igR 8h9w== X-Gm-Message-State: ALoCoQlh6o1+itJh8VGXe7tdRtPILhSPOY9IVTb5h/8EdCDsVXtpuW82wvvSNobhvgGQ0U4dcCxR X-Received: by 10.49.58.225 with SMTP id u1mr18981076qeq.55.1382814112036; Sat, 26 Oct 2013 12:01:52 -0700 (PDT) Received: from [192.168.100.127] (mobile-166-186-168-220.mycingular.net. [166.186.168.220]) by mx.google.com with ESMTPSA id h9sm33581113qaq.9.2013.10.26.12.01.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Oct 2013 12:01:51 -0700 (PDT) Message-ID: <526C119C.3030806@joyent.com> Date: Sat, 26 Oct 2013 15:01:48 -0400 From: Robert Mustacchi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; 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> In-Reply-To: <20131026180643.GA98676@raichu> 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: Sat, 26 Oct 2013 19:24:19 -0000 On 10/26/13 14:06 , Mark Johnston wrote: > On Fri, Oct 25, 2013 at 07:30:45PM +0300, Andriy Gapon wrote: >> on 24/10/2013 19:16 Mark Johnston said the following: >>> On Thu, Oct 24, 2013 at 01:20:17PM +0300, Andriy Gapon wrote: >>>> >>>> Can our SDT (for kernel) implementation support probes with unspecified types >>>> for arguments? >>>> I would like to get DTRACE_PROBE*() which can be found in the code with >>>> OpenSolaris origins (e.g. ZFS) to work. With minimal efforts :-) >>> >>> Hm, it looks like illumos uses the first argument to DTRACE_PROBE* to >>> specify both the provider name and probe name; if no provider name is >>> given (based on a lookup in a table in sdt_subr.c), a default "sdt" >>> provider is used. It looks like this is what's happening for the ZFS >>> probes. >>> >>> I'd suggest something like the following: >>> - to kern_sdt.c, add >>> >>> SDT_PROVIDER_DEFINE(sdt); >>> >>> - add DTRACE_PROBE* macros to sdt.h which invoke SDT_PROBE* with the sdt >>> provider, i.e. something like >>> >>> #define DTRACE_PROBE1(name, type, arg) \ >>> SDT_PROBE1(sdt, , , name, arg) >>> >>> - add a FreeBSD-only zfs_dtrace.c which contains the SDT_PROBE_DEFINE* >>> invocations for the ZFS probes. You can define the types there, or not >>> (using an empty string or NULL should work, I'm not sure). >>> >>> This won't work for illumos code where the probes specify a provider, >>> but I think that's ok. I can do the first two steps if you agree with >>> this approach. I don't have any way to test the ZFS probes at the >>> moment, but I guess I can provide a zfs_dtrace.c too if you (or anyone >>> else) can test. >> >> Mark, >> >> thank you for the ideas! The approach sounds fine to me. >> I plan to have some time to work on this next week. >> I will definitely be able to test things and maybe even develop something. >> So, thank you again. > > 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. :) Hi Mark, Your reading of what's going on in sdt_subr.c is right. We're basically just using a prefix on the SDT probe name to effectively namespace the probe to a provider. And if it's currently an unknown provider then we just end up putting it into the sdt module. All those zfs probes are just in the SDT provider for now, we don't have a stable ZFS provider yet. From my reading of what you've done it looks like you've created compatibly named probes. Robert