From owner-freebsd-dtrace@FreeBSD.ORG Thu Jul 25 15:17:20 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 73C9241E; Thu, 25 Jul 2013 15:17: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 880ED2E54; Thu, 25 Jul 2013 15:17:16 +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 SAA10812; Thu, 25 Jul 2013 18:17:09 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V2NHw-000DNP-UI; Thu, 25 Jul 2013 18:17:08 +0300 Message-ID: <51F14150.7000509@FreeBSD.org> Date: Thu, 25 Jul 2013 18:16:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: markj@FreeBSD.org Subject: Re: [RFC] reworking FreeBSD's SDT implementation References: <20130703041023.GA82673@raichu> <20130711024500.GA67976@raichu> <20130711210215.GB7506@gmail.com> <20130713234200.GA40803@raichu> <20130714075634.GC2832@gmail.com> <20130722022811.GA14288@raichu> In-Reply-To: <20130722022811.GA14288@raichu> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Thu, 25 Jul 2013 15:17:20 -0000 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? -- Andriy Gapon