From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <13426df10910312026g19bde105mc0e5b2b68487cf15@mail.gmail.com> References: <1f9dd4633f6c8737e5b2722e0af23588@brasstown.quanstro.net> <13426df10910271923r1e030dc7u7b198678866ae949@mail.gmail.com> <3C95D7D1-0518-449E-8711-DA90EF1B7183@mac.com> <13426df10910312026g19bde105mc0e5b2b68487cf15@mail.gmail.com> Date: Sun, 1 Nov 2009 13:00:48 +0800 Message-ID: From: Roman Shaposhnik To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] dtrace for plan 9 Topicbox-Message-UUID: 9515563a-ead5-11e9-9d60-3106f5b1d025 On Sun, Nov 1, 2009 at 11:26 AM, ron minnich wrote: > On Sat, Oct 31, 2009 at 8:01 PM, =A0 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 liftin= g >> on? > > yeah. You are right. Is there any reason that D couldn't always run in > user mode, having read from a device which delivers events to it? > > I'm not really that familiar with dtrace, as you can tell; I've just > read the papers, not really used it. The whole point of D is to be able to execute scripts in kernel mode (and sometime in tricky places like interrupt handlers, etc). The main reason of doing that is to be able to filter in place what is it that you want to sen= d to userland /dev/dtrace and what you just want to discard. That gives you a huge reduction in event traffic at a price of restricting D. Lack of loop= ing is the prime example of such a restriction. As for your question -- I have to ask you back: why would you want to? IOW, why would you still want to restrict yourself in user mode? If you simply w= ant to pipe all events to an aggregation engine won't: # dtrace -n 'whatever spec' | awk 'do postprocessing here' be what you really want? Thanks, Roman.