svn commit: r189063 - head/sys/kern

[Alexander Leidinger]

Quoting Robert Watson <rwatson at 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 at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscribe at freebsd.org"