From owner-freebsd-dtrace@FreeBSD.ORG Sat Nov 2 04:12:46 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 836CA24A; Sat, 2 Nov 2013 04:12:46 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4322A2DDE; Sat, 2 Nov 2013 04:12:46 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id ar20so8667965iec.26 for ; Fri, 01 Nov 2013 21:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=DkoW/v8U5QWlsnV/3tqXgMXnEp4dXN/FNs0Jw3TR6G4=; b=qLjA1qy6NZHJGmoCMVaNR+qprhSxy7DXHeRNVbHGGw5Svh3OtZoSL0xcxKPGXsXBkV FU63i2bzV96JB9mAMImpzK/6LXqccFReWnE5vIXt4BUi/T19VcB9BFU5dxzbipqJVFj8 ARYgJcIfey4R7plQXcMhl/JeIIWt4lkwRtqzjKdDVzvtGO0ASx9NU0KfSsOHnrYvVXtv TMlO8jmID8JQPkCURiWyTK+XEQwgEeRdAWdlkMWNMJdQIvb4NvESLSP7Loc16QqpbZxr XNcp/CWkLsYesGTP/5drN5qIqXiYAaLx5ZjXQEXRxjHCsnMOwn/wFPZZvr7LtoCBeEoS utbA== X-Received: by 10.50.66.101 with SMTP id e5mr4939082igt.26.1383365565680; Fri, 01 Nov 2013 21:12:45 -0700 (PDT) Received: from raichu (24-212-218-13.cable.teksavvy.com. [24.212.218.13]) by mx.google.com with ESMTPSA id qi3sm7187998igc.8.2013.11.01.21.12.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 21:12:44 -0700 (PDT) Sender: Mark Johnston Date: Sat, 2 Nov 2013 00:12:40 -0400 From: Mark Johnston To: Andriy Gapon Subject: Re: "unstable" sdt probes Message-ID: <20131102041240.GA23329@raichu> References: <5268F461.7080504@FreeBSD.org> <20131024161620.GA1710@charmander> <526A9CB5.2050207@FreeBSD.org> <20131026180643.GA98676@raichu> <527026B3.2070309@FreeBSD.org> <20131031035523.GD9355@raichu> <52720017.3060809@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52720017.3060809@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 02 Nov 2013 04:12:46 -0000 On Thu, Oct 31, 2013 at 09:00:39AM +0200, Andriy Gapon wrote: > 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. Sure, there are multiple probe sites for the sdt:::arc-miss probe, for example. For the ip provider, there are multiple probe sites for ip:::receive: at least one for IPv4, and at least one for IPv6. > > >> 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