From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 12 07:38:35 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41F20106564A for ; Sun, 12 Dec 2010 07:38:35 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E18E78FC15 for ; Sun, 12 Dec 2010 07:38:34 +0000 (UTC) Received: by vws9 with SMTP id 9so3012265vws.13 for ; Sat, 11 Dec 2010 23:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=+fCsIpFPSZOFwYUwZPDjBZtkdEGCfUoCGl0cYLBV53s=; b=ktbk6RE2OpmFFaB5KR0bQAHolkJzHkkbJ71gHZ30HZGa5Nokub3dL2/I9IDyCyIdwE vW+7egPP0U4mXAMCLaM4qxDmUSZ0vSr0U5ywmzr5f44TJuaqY71AqljeyYUz+BVot1j+ b7uNGLTIAhLXPbtjOEuMQoaw++I8RdwJmkchI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=wiQpm09Kd2jshGqufqwV1mst6/A7qvd6Z5CuurnfXIvqodY3Hj5uIhwI6Kc5bz0Nmr aq8IbSR2F1tUeITCENDvXIccbON0PXob9xTkrllm8zjcs8F+dBtRqx3meHf2hRxmnQ7F Mz1fWl+Ia7SV5+h5xOyQgY598j0tOQfNhJdV0= MIME-Version: 1.0 Received: by 10.220.193.203 with SMTP id dv11mr854342vcb.1.1292139512708; Sat, 11 Dec 2010 23:38:32 -0800 (PST) Sender: artemb@gmail.com Received: by 10.220.177.195 with HTTP; Sat, 11 Dec 2010 23:38:32 -0800 (PST) In-Reply-To: <20101211215341.0000097c@unknown> References: <20101211215341.0000097c@unknown> Date: Sat, 11 Dec 2010 23:38:32 -0800 X-Google-Sender-Auth: S-fSv6Csd3w1hmHpCXNM_q6DKBY Message-ID: From: Artem Belevich To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: syscall provider naming convention. Re: kern/152822: [patch] DTrace: syscall provider for compat/freebsd32 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 07:38:35 -0000 > Maybe a little bit related: do you know about my (unfortunately > out-of-date) branch to add dtrace providers to the linuxulator? > http://svn.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/ > > If you are interested feel free to borrow things from there. I'll take a look. >> I'm leaning towards using 'module' but I would appreciate hackers@ >> opinion on the best way to proceed. > > My first thought was that this is a good idea. > > My second thought was the question if you can make the provided values > there compatible enough that a dtrace script is able to cope with it > when someone does not uses a specific module but the wirldcard > operator. If not I suggest to think again about it. Installing wildcard probes should work fine either way. If we use module to differentiate between emulation variants then syscall::write:entry will install probes for all variants of write syscall. In cases when we use wildcard syscall probes that would typically be the right thing to do. For instance, in case of one-liner like 'syscall:::entry { @num[pid,execname] = count(); }'. That's in fact why I started tinkering with this -- the one-liner above didn't show anything for 32-bit binaries I've been running. On the other hand, most of the current scripts that use syscall provider do not specify module. Such scripts would now match more than one syscall. I.e. if the intent was to catch only native write syscall, the probe would now be installed for freeebsd32 and linux32 variants as well. Given the fact that most of available Dtrace scripts that come from Solaris need modifications/tweaking anyways, that's probably not such a big deal. If we use different provider names, then one could do syscall*::write: and that would work, too. This reverses situation above. Current wildcard probes will remain limited to native syscalls and would need to be changed. If someone would want to include syscalls from other emulation layers they would have to explicitly install probes for corresponding providers. Functionally both approaches are about the same functionally. Each has pluses and minuses. Using module, though, looks somewhat cleaner. --Artem