From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Message-id: <3C95D7D1-0518-449E-8711-DA90EF1B7183@mac.com> From: dave.l@mac.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Date: Sun, 1 Nov 2009 03:01:13 +0000 References: <1f9dd4633f6c8737e5b2722e0af23588@brasstown.quanstro.net> <13426df10910271923r1e030dc7u7b198678866ae949@mail.gmail.com> Subject: Re: [9fans] dtrace for plan 9 Topicbox-Message-UUID: 9500e4fc-ead5-11e9-9d60-3106f5b1d025 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 (trust me: I administer hairy systems and dtrace has definitely helped us), and some of the ideas are good, but the whole thing is a mess. Maybe I'm missing something, 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? Also, you don't want a debugger, you want a data analyser: awk, maybe? Dave. On 28 Oct 2009, at 02:38, Jeff Sickel wrote: > 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 a way to use acid and the linker to provide the > kinds of hooks you want for debugging. > > -jas > > On Oct 27, 2009, at 9:23 PM, ron minnich wrote: > >> 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 > >