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 =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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090226155442.999858tszd64utki>