From owner-freebsd-dtrace@FreeBSD.ORG Sun Aug 4 01:51:29 2013 Return-Path: Delivered-To: freebsd-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 10347E32; Sun, 4 Aug 2013 01:51:29 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B22222662; Sun, 4 Aug 2013 01:51:28 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id bs12so365500qab.14 for ; Sat, 03 Aug 2013 18:51:27 -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=8aYLIA64x5iYog879RCPpJQrNA6Eh01r8BNGLKySdHE=; b=mfAlG0duxRUexLXRi6Zcln3tpTC5APVag6OFV9F7vrLU74LKv4dMDl1gZ/Vsq3Fhgp O4uy/Ogy1VJiJ8FgBiGE3WVP2azRv9quxtn+oolN6bjUwzvLv/GdlOVqDsdxIZ5XGAWO h8VAfksGuu5Nco0IP35s0/TLmS+CC3M+/KVxRlQKEubsQiqQ+Y/lFUuspAY0e7/p0JJ0 x3BiW3juFz//qFkmY+doqLHo3TWHq6334ajbl4ABVqUfHs56lvUVwSiDRkns7RCt8XjK i4cw0QOvWqtv1TUe4MjT6OiNuFMvr35kvdyToeVg+zAC0PB7Zotfqow9/9hh81SHa1qW eGbA== X-Received: by 10.49.104.114 with SMTP id gd18mr17687787qeb.17.1375581087736; Sat, 03 Aug 2013 18:51:27 -0700 (PDT) Received: from raichu (24-212-218-13.cable.teksavvy.com. [24.212.218.13]) by mx.google.com with ESMTPSA id a2sm4465778qek.7.2013.08.03.18.51.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Aug 2013 18:51:26 -0700 (PDT) Sender: Mark Johnston Date: Sat, 3 Aug 2013 21:51:22 -0400 From: Mark Johnston To: Andriy Gapon Subject: Re: [RFC] reworking FreeBSD's SDT implementation Message-ID: <20130804015122.GA3259@raichu> References: <20130703041023.GA82673@raichu> <20130711024500.GA67976@raichu> <20130711210215.GB7506@gmail.com> <20130713234200.GA40803@raichu> <20130714075634.GC2832@gmail.com> <20130722022811.GA14288@raichu> <51F14150.7000509@FreeBSD.org> <20130727022656.GB67227@raichu> <51F372C8.1000107@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51F372C8.1000107@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-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: Sun, 04 Aug 2013 01:51:29 -0000 On Sat, Jul 27, 2013 at 10:12:08AM +0300, Andriy Gapon wrote: > on 27/07/2013 05:26 Mark Johnston said the following: > > On Thu, Jul 25, 2013 at 06:16:32PM +0300, Andriy Gapon wrote: > >> on 22/07/2013 05:28 markj@freebsd.org said the following: > >>> http://people.freebsd.org/~markj/patches/sdt-module-info/20130721-sdt-module-info.diff > >> > >> Mark, > >> > >> this is a minor suggestion only partially related to your patch. > >> I think that it would be nice if module loading and unloading events were posted > >> via EVENTHANDLER(9) mechanism. Then instead of introducing yet more DTrace > >> related hooks in the kernel code, DTrace modules could just subscribe to those > >> events. Also, those events could be potentially useful to other consumers > >> beyond DTrace. > >> What do you think? > > > > Hm, now that I look at this, I'm not sure if it can work. The unload > > hooks need to be able to veto a module unload in the case that one of > > its probes is enabled. This is done by checking whether lf->nenabled > 0, > > and it needs to be done with the dtrace lock held to prevent races. > > > > I've done this by having the unload hooks return a non-zero value if > > there are probes enabled, but EVENTHANDLER(9) doesn't give me a way to > > look at a handler's return value. Do you see a way to get around this? > > Hmm, I didn't think about this problem in advance... > Having looked around I think that it should be possible to handle this situation > in a way similar to watchdog_list. watchdog(9) documents how that works. Of > course, all handlers will have to be careful to not override error if it's > already set. I implemented the module load/unload events a couple of days ago using EVENTHANDLER(9), and it looks like everything works properly. I copied the trick used for watchdog_list and just added an error pointer argument to the unload handlers. The revised patch is here: http://people.freebsd.org/~markj/patches/sdt-module-info/20130803-sdt-module-info.diff Thanks! -Mark