Would this answer your question:
http://blogs.sun.com/jonh/entry/the_dtrace_deadman_mechanism
Well, it answers the question "What is the DTrace so-called deadman
mechanism?" I think.
That's a sort of part of a possible solution, which is OK.
To be pedantic, it's not a true deadman mechanism
On Tue, Nov 10, 2009 at 12:21 PM, wrote:
> On 10 Nov 2009, at 01:00, Roman Shaposhnik wrote:
>>
>> What exactly do you want to know? I worked with DTrace quite extensively.
>
> What is the upper bound on the runtime of a single D bytecode sequence?
>
> Or to put it another way, what's the longest
On 10 Nov 2009, at 01:00, Roman Shaposhnik wrote:
What exactly do you want to know? I worked with DTrace quite
extensively.
What is the upper bound on the runtime of a single D bytecode sequence?
Or to put it another way, what's the longest time delay that DTrace&co
can cause in your kernel
On Mon, Nov 9, 2009 at 7:08 PM, Devon H. O'Dell wrote:
> 2009/11/9 erik quanstrom :
> That said, my knowledge of DTrace internals greatly surpasses my knowledge of
> how to
> actually use it, so I'll let Roman help out on that front :)
Which means -- we can nicely compliment each other ;-)
>> b
2009/11/9 erik quanstrom :
>> DTrace by itself is pretty lame. It needs providers to be interesting.
>> By itself, it's a very limited interpreter that supports BEGIN and
>> END, and a couple other tiny things (ERROR, maybe?). Devtrace would be
>> analogous to the syscall provider for DTrace, from
> DTrace by itself is pretty lame. It needs providers to be interesting.
> By itself, it's a very limited interpreter that supports BEGIN and
> END, and a couple other tiny things (ERROR, maybe?). Devtrace would be
> analogous to the syscall provider for DTrace, from my understanding.
i may be mis
2009/11/9 erik quanstrom :
>> > I keep hearing this brought up, but (while I am not an expert) AFAICT, the
>> > runtime for each D hook should be strictly bounded by the number of
>> > instructions lobbed in, since D does not (without root override, perhaps?)
>> > support backwards jumps. Am I mis
> > I keep hearing this brought up, but (while I am not an expert) AFAICT, the
> > runtime for each D hook should be strictly bounded by the number of
> > instructions lobbed in, since D does not (without root override, perhaps?)
> > support backwards jumps. Am I mistaken in my understanding of DT
On Mon, Nov 9, 2009 at 4:46 PM, ron minnich wrote:
> On Mon, Nov 9, 2009 at 4:33 PM, Nathaniel W Filardo wrote:
>> On Mon, Nov 09, 2009 at 12:07:22AM +, dav...@mac.com wrote:
>>> yet too dangerous due to its possible unbounded runtime
>>
>> I keep hearing this brought up, but (while I am not
On Mon, Nov 9, 2009 at 4:33 PM, Nathaniel W Filardo wrote:
> On Mon, Nov 09, 2009 at 12:07:22AM +, dav...@mac.com wrote:
>> yet too dangerous due to its possible unbounded runtime
>
> I keep hearing this brought up, but (while I am not an expert) AFAICT, the
> runtime for each D hook should b
On Mon, Nov 9, 2009 at 4:33 PM, Nathaniel W Filardo wrote:
> On Mon, Nov 09, 2009 at 12:07:22AM +, dav...@mac.com wrote:
>> yet too dangerous due to its possible unbounded runtime
>
> I keep hearing this brought up, but (while I am not an expert) AFAICT, the
> runtime for each D hook should b
On Mon, Nov 09, 2009 at 12:07:22AM +, dav...@mac.com wrote:
> yet too dangerous due to its possible unbounded runtime
I keep hearing this brought up, but (while I am not an expert) AFAICT, the
runtime for each D hook should be strictly bounded by the number of
instructions lobbed in, since D
> Note that we can filter on up to 16 PIDs already. Also, you can grow
> the buffer space to 256 KB -- but yes, we could grow it further.
i upped that pidwatch limit to 64 and added a binary search on the
pid array, so 64 is really an arbitrary limit. there would be
essentially no cost to upping
On Mon, Nov 9, 2009 at 6:28 AM, erik quanstrom wrote:
> with devtrace, the situation is the opposite. jitter is
> important (to eliminate), 541 small fixed-sized events can
> be returned per system call and there is one trace device
> per system.
Note that we can filter on up to 16 PIDs already
On Sun Nov 8 19:58:08 EST 2009, rminn...@gmail.com wrote:
> On Sun, Nov 8, 2009 at 4:07 PM, wrote:
>
> > I'd be happy to see a BPF-style filter in the kernel for filtering events
> > before chucking them up to userland,
>
> Point taken. I could pretty easily put a simple filter like that in
>
On Sun, Nov 8, 2009 at 4:07 PM, wrote:
> I'd be happy to see a BPF-style filter in the kernel for filtering events
> before chucking them up to userland,
Point taken. I could pretty easily put a simple filter like that in
devtrace. It's just a question of what's needed.
ron
> The latter uses less time and effort and doesn't Heisenberging your kernel
> nearly so much.
I can also recommend Newtoning from a high cliff.
One thing I suspect people may be forgetting in the race to emulate YA
feechure of YA UNIX variant is that
one of the reasons for DTrace's complexities (hierarchical namespace,
in-kernel interpreter)
is the complexity of the Solaris kernel.
When they're trying to work out how a thread in a pr
I don't know anything specific about DTrace,
but I'm thinking a clear,
consistent interface for logging and tracing kernel operations sounds
like a good thing.
So am I, but how does this relate to dtrace?
D
On Sat, Nov 7, 2009 at 2:45 AM, Ethan Grammatikidis wrote:
> I don't know anything specific about DTrace, but I'm thinking a clear,
> consistent interface for logging and tracing kernel operations sounds
> like a good thing.
I have seen several use cases for DTrace and one thing that I would
fin
A comment in MacFUSE changelog got me thinking. Here's the comment:
For example, look at the updated LoopbackFS example file system: the
logging code from it has been removed because better tracing information
can be had using DTrace. Consequently, the file system code is shorter
and easier to rea
On Tue, Nov 3, 2009 at 4:29 PM, Lyndon Nerenberg wrote:
>> i was told dtrace was non-intrusive at the time, but w2 would show the
>> command history from w1.
>
> More likely this is ksh sharing a history file.
>
>
at the time i couldn't reproduce it with other shells. anyway, iirc,
no such side-e
i was told dtrace was non-intrusive at the time, but w2 would show the
command history from w1.
More likely this is ksh sharing a history file.
On Sun, Nov 1, 2009 at 4:44 PM, Nathaniel W Filardo wrote:
> On Sun, Nov 01, 2009 at 11:58:10AM -0500, erik quanstrom wrote:
>> On Sun Nov 1 11:55:47 EST 2009, devon.od...@gmail.com wrote:
>> > Also, D is not compiled in kernel. The dtrace utility compiles the D
>> > script, and the script goes t
On Sun, Nov 1, 2009 at 9:03 PM, erik quanstrom wrote:
> > Some people find the idea of writing their own kernel code "scary".
> > To those who don't I imagine d-trace has less appeal.
>
> sure thing. plan 9, by being simple, makes the kernel
> a much less scary place to be.
>
> by the way, many o
> Some people find the idea of writing their own kernel code "scary".
> To those who don't I imagine d-trace has less appeal.
sure thing. plan 9, by being simple, makes the kernel
a much less scary place to be.
by the way, many of the same people have now decided
that library code is scary. :-)
that's a scary idea. i wouldn't run anything like
that outside of testing. and so why wouldn't i just
write a bit of custom code?
Some people find the idea of writing their own kernel code "scary".
To those who don't I imagine d-trace has less appeal.
- erik
Tim Newsham
http://www.thenewsh
On Sun, Nov 01, 2009 at 11:58:10AM -0500, erik quanstrom wrote:
> On Sun Nov 1 11:55:47 EST 2009, devon.od...@gmail.com wrote:
> > Also, D is not compiled in kernel. The dtrace utility compiles the D
> > script, and the script goes through some sanity checking in the D
> > compiler. The bytecode i
On Sun, Nov 1, 2009 at 9:52 AM, Devon H. O'Dell wrote:
> Also, D is not compiled in kernel. The dtrace utility compiles the D
> script, and the script goes through some sanity checking in the D
> compiler. The bytecode is sent to the kernel to execute. There are
> some in-kernel safety guarantees
On Sun Nov 1 11:55:47 EST 2009, devon.od...@gmail.com wrote:
> Also, D is not compiled in kernel. The dtrace utility compiles the D
> script, and the script goes through some sanity checking in the D
> compiler. The bytecode is sent to the kernel to execute. There are
> some in-kernel safety guara
Also, D is not compiled in kernel. The dtrace utility compiles the D
script, and the script goes through some sanity checking in the D
compiler. The bytecode is sent to the kernel to execute. There are
some in-kernel safety guarantees -- for instance, a D script causing a
nil ptr deref in kernel ob
> hmm, I'm always writing the similar debugging code for the kernel, I
> know I'll write a bit of custom code.
>
> ... some time later
>
> hmm, I'm always writing the similar post processing scripts, I know I'll
> add a callback before each print
we have acid for a reason. dtrace isn't a
/me imagines it goes like this :
hmm, I'm always writing the similar debugging code for the kernel, I
know I'll write a bit of custom code.
... some time later
hmm, I'm always writing the similar post processing scripts, I know I'll
add a callback before each print
> The whole point of D is to be able to execute scripts in kernel mode (and
> sometime in tricky places like interrupt handlers, etc).
that's a scary idea. i wouldn't run anything like
that outside of testing. and so why wouldn't i just
write a bit of custom code?
- erik
On Sun, Nov 1, 2009 at 11:26 AM, ron minnich wrote:
> On Sat, Oct 31, 2009 at 8:01 PM, wrote:
>
>> but wouldn't be slightly nicer to have something like a set of dynamic
>> probes
>> which queue up blobs of data up for userland code to do the hairy lifting
>> on?
>
> yeah. You are right. Is ther
On Sat, Oct 31, 2009 at 8:01 PM, wrote:
> but wouldn't be slightly nicer to have something like a set of dynamic
> probes
> which queue up blobs of data up for userland code to do the hairy lifting
> on?
yeah. You are right. Is there any reason that D couldn't always run in
user mode, having re
Having banged my head against D's rampant inconsistency and almost but
not quite total dissimilarity to awk,
I think even acid's intemperate lingo is preferable.
OTOH, the idea of chucking ANY language interpreter into a kernel
seems wrong too.
Yes, dtrace dtrace/D provide great capabilities
Yes please. I'd hate to see the Plan 9 ideas turned into subjecting
some unfortunate programmer(s) with having to write hundreds of
thousands of probes instead of following the more acid based approach.
dtrace has it's place. And as you've said, eye candy wins. But I
still think there's
One other thought on this line. The dtrace tools include a kernel
module which understands the dtrace language. Maybe an alternative
plan 9 approach is a kernel driver which understands acid.
ron
On Tue Oct 27 20:22:00 EDT 2009, rminn...@gmail.com wrote:
> I realize it is early but a neat GSOC project would be to take the
> mods I made to 8l and friends and use these as a way to build dtrace
> for plan 9.
a more centrally plan 9 project would be to build a coverage
analysis tool. that may
2009/10/27 ron minnich :
> I realize it is early but a neat GSOC project would be to take the
> mods I made to 8l and friends and use these as a way to build dtrace
> for plan 9.
Getting CTF working in Plan 9 would be difficult since it's not ELF.
It was annoying enough to get working in FreeBSD.
41 matches
Mail list logo
