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: From: dave.l@mac.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Date: Mon, 9 Nov 2009 00:07:22 +0000 References: <55c52a87f0b8c0ac12a81a150f110b2b@brasstown.quanstro.net> <20091101184418.GM19125@gradx.cs.jhu.edu> <1257590719.28012.1344036163@webmail.messagingengine.com> Subject: Re: [9fans] dtrace for plan 9 Topicbox-Message-UUID: 980e53d2-ead5-11e9-9d60-3106f5b1d025 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 proc in a zone in an ldom got to spin on a lock, you *need* awk in your kernel to work out wtf is going on. (In fact, for the serious cases, to me, D feels too limited to be useful because of it's deliberate restrictions, yet too dangerous due to its possible unbounded runtime ). In reality, for many cases, something simpler does the job better: other people use DTrace to do what I would do with truss(1) and a few joined-up braincells. The latter uses less time and effort and doesn't Heisenberging your kernel nearly so much. On plan9 this is even more the case. I'd be happy to see a BPF-style filter in the kernel for filtering events before chucking them up to userland, but a language interpreter and all the associated mess, overheads and potential security holes? No thanks. D On 8 Nov 2009, at 14:19, dave.l@mac.com 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. > > > So am I, but how does this relate to dtrace? > > D > >