From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Sun,  1 Nov 2009 11:58:10 -0500
To: 9fans@9fans.net
Message-ID: <55c52a87f0b8c0ac12a81a150f110b2b@brasstown.quanstro.net>
In-Reply-To: <<9ab217670911010852h46cc32a0k2e3ef99323287595@mail.gmail.com>>
References: <<9ab217670911010852h46cc32a0k2e3ef99323287595@mail.gmail.com>>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] dtrace for plan 9
Topicbox-Message-UUID: 9534ab66-ead5-11e9-9d60-3106f5b1d025

On Sun Nov  1 11:55:47 EST 2009, devon.odell@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 guarantees -- for instance, a D script causing a
> nil ptr deref in kernel obviously shouldn't (and does not) cause the
> system to panic.

that wasn't my main concern.

there are many interrupt routines that depend on
the exact sequence of events and probing  is likely
to wreck havoc.

how do you prevent probes from reading read-to-clear
registers?

how do you know a probe in an irq routine won't set
off a latent race?

- erik