From owner-svn-src-head@FreeBSD.ORG Thu Feb 26 14:54:54 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8228106566B; Thu, 26 Feb 2009 14:54:54 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 20F898FC13; Thu, 26 Feb 2009 14:54:53 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2CC5D.dip.t-dialin.net [217.226.204.93]) by redbull.bpaserver.net (Postfix) with ESMTP id 9AE202E1F9; Thu, 26 Feb 2009 15:54:47 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id B105A143983; Thu, 26 Feb 2009 15:54:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1235660083; bh=9Due+gTNFp94kQzrrt9NOUzZwcletojtu paQ7QgYTB8=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iEn2FxU4wHqKrVyXGNiICVmLBMc/w0iZFBl2IC5PmA6duunlmpk48p3tUzvkPBX5O 7g7fhFqZf9YUk3h0w8iQZTxpVOym0ToowOk/Ite+VMD0HpOuCEfv6z722s7vxnhopTQ jdmnTx5QC2f6WzABo9485wakZ1U4EeywLtmNZ/A/ImpjmEAdFiprV5OgcjDMn6GdN5i 2YoIjTo60RlEpsmTURjjmewqdOQ83L9s9EaERq/yLWvNy0a487IaQ941zGzASS8cqdE qGveet5ndqdz8eD4bA6SfPoDEt/Y+Q/f5ODm8pNX44obBAoCaCOkYkMWwsiaWUD0pKB z9d6V6wOQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n1QEsg1O069019; Thu, 26 Feb 2009 15:54:42 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 26 Feb 2009 15:54:42 +0100 Message-ID: <20090226155442.999858tszd64utki@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 26 Feb 2009 15:54:42 +0100 From: Alexander Leidinger To: Robert Watson References: <200902261056.n1QAuDTL025375@svn.freebsd.org> <20090226134937.13523qtfgxc9ik7k@webmail.leidinger.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 9AE202E1F9.CDF3A X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-13.427, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10, TW_SV 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r189063 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 14:54:55 -0000 Quoting Robert Watson (from Thu, 26 Feb 2009 =20 13:33:18 +0000 (GMT)): > > On Thu, 26 Feb 2009, Alexander Leidinger wrote: > >>> A typical tracing command might be: >>> >>> dtrace -n 'priv:::priv_ok { trace(execname); trace(arg0);}' >>> >>> arg0 requires manual interpretation using /usr/include/sys/priv.h. >> >> Theoretically it is possible to write a little script which takes =20 >> priv.h and generates a little bit of dtrace stuff which allows to =20 >> print out strings instead of numbers. But I think this is a matter =20 >> of motivation... >> >> I would also use printf("program: %s, priv: $d\n", execname, arg0) =20 >> or something similar with printf, but this is cosmetics. >> >> Should we create a repository of dtrace scripts in /usr/share or =20 >> wherever? For the linuxulator I have several scripts in my =20 >> linuxulator-dtrace branch (some more, some less useful for =20 >> non-developers). > > I have a couple up on the wiki on the DTrace/Examples page from some =20 > callout-related profiling I was doing, but some sort of more formal =20 > library would be good. I guess the question is "how productionable =20 > do we want them to be" -- if they're just fragments then a wiki or =20 > the tools tree might be good; if it's really going to be a formal set I was thinking about having stuff which is useful for users there. =20 This means either good stuff for casual users like "show me all failed =20 priv checks" (even if the snipped is small, sometimes you just want to =20 know the result without the need to learn how to get it), or =20 large/interesting stuff like my check_error.d =20 (http://svnweb.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/src/= sys/compat/linux/check_error.d?revision=3D186949&view=3Dmarkup) which can be= useful to detect interesting =20 things. Things which are only useful in a more specific context are ok in the =20 wiki. To me it looks your "show me all priv_ok probes" snippet is only =20 useful in a more specific context, like triggering the probe for a =20 particular executable which gets access where it shouldn't, so this =20 would be a candidate for the wiki. Regarding your callout scripts I think it would make sense to have =20 them in src-tree (but not intalled into the /usr/share/... repository, =20 as they do not seem to be that useful for non-FreeBSD-developers) =20 instead in the wiki. This way developers have them at hand together =20 with the src, instead of searching in the wiki for something useful =20 (or worse, no access at all when you are on a plane/train without net =20 access and want to quickly have a look at something related). > of analysis tools with consistent interface, style, and maintained =20 > over time then usr/share would be better, but I think having =20 > consistency in approach and content would be something very much to =20 > encourage. Yes, just a dumpster of d-scripts without some policy for it could be =20 of questionable usefulness (the really useful ones could become the =20 needle in the haystack in the worst case). My policy would be: - useful for users (size doesn't matter, in critical situations you don't have the time to research how to do it) - big examples (but probably in a "script needs to be extended to be useful" folder) - related to + error checking (application errors, userland programming errors, and maybe even some kind of kernel programming errors like invariants checking) + userland performance (e.g. the callout snippets help developers to improve the kernel, so they are out, but something which measures the service time of disk i/o should be in, as the user could detect failing hardware or opt to buy faster hardware) + resource info/checking + policy checking (like your priv check in the failed case) + ... (most probably I forgot something useful) Development stuff I would just put at the corresponding places near =20 the code in src, or if it is something generic maybe in src/tools/... Bye, Alexander. --=20 Anyone stupid enough to be caught by the police is probably guilty. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137