Date: Thu, 26 Feb 2009 15:54:42 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r189063 - head/sys/kern Message-ID: <20090226155442.999858tszd64utki@webmail.leidinger.net> In-Reply-To: <alpine.BSF.2.00.0902261331250.41191@fledge.watson.org> References: <200902261056.n1QAuDTL025375@svn.freebsd.org> <alpine.BSF.2.00.0902261056280.16988@fledge.watson.org> <20090226134937.13523qtfgxc9ik7k@webmail.leidinger.net> <alpine.BSF.2.00.0902261331250.41191@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Robert Watson <rwatson@FreeBSD.org> (from Thu, 26 Feb 2009 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 >> priv.h and generates a little bit of dtrace stuff which allows to >> print out strings instead of numbers. But I think this is a matter >> of motivation... >> >> I would also use printf("program: %s, priv: $d\n", execname, arg0) >> or something similar with printf, but this is cosmetics. >> >> Should we create a repository of dtrace scripts in /usr/share or >> wherever? For the linuxulator I have several scripts in my >> linuxulator-dtrace branch (some more, some less useful for >> non-developers). > > I have a couple up on the wiki on the DTrace/Examples page from some > callout-related profiling I was doing, but some sort of more formal > library would be good. I guess the question is "how productionable > do we want them to be" -- if they're just fragments then a wiki or > 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. This means either good stuff for casual users like "show me all failed priv checks" (even if the snipped is small, sometimes you just want to know the result without the need to learn how to get it), or large/interesting stuff like my check_error.d (http://svnweb.freebsd.org/viewvc/base/user/netchild/linuxulator-dtrace/src/sys/compat/linux/check_error.d?revision=186949&view=markup) which can be useful to detect interesting things. Things which are only useful in a more specific context are ok in the wiki. To me it looks your "show me all priv_ok probes" snippet is only useful in a more specific context, like triggering the probe for a particular executable which gets access where it shouldn't, so this would be a candidate for the wiki. Regarding your callout scripts I think it would make sense to have them in src-tree (but not intalled into the /usr/share/... repository, as they do not seem to be that useful for non-FreeBSD-developers) instead in the wiki. This way developers have them at hand together with the src, instead of searching in the wiki for something useful (or worse, no access at all when you are on a plane/train without net access and want to quickly have a look at something related). > of analysis tools with consistent interface, style, and maintained > over time then usr/share would be better, but I think having > consistency in approach and content would be something very much to > encourage. Yes, just a dumpster of d-scripts without some policy for it could be of questionable usefulness (the really useful ones could become the 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 the code in src, or if it is something generic maybe in src/tools/... Bye, Alexander. -- Anyone stupid enough to be caught by the police is probably guilty. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090226155442.999858tszd64utki>