Re: Revisiting DTrace syscall provider

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Wed, Feb 25, 2015 at 4:10 AM, bch <brad.harder%gmail.com@localhost> wrote:
> w/ latest -current:
>
> % dtrace -l
> BEGIN
> END
> ERROR
> % dtrace -n BEGIN
> <fault/reboot>
>
>
> This is w/o loading any kernel modules, but the probes are still
> listed as available, but then fault.

Autoloading modules is a feature of NetBSD. You can see solaris.kmod
and dtrace.kmod are loaded after dtrace -l. Note that BEGIN, END,
ERROR are 'dtrace' provider that is included in dtrace.kmod.

OTOH, the fault should be a bug. I'm investigating it.

Thank you for pointing it out.
  ozaki-r


>
> -bch
>
>
>
> On 2/23/15, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>> On Tue, Feb 24, 2015 at 1:55 PM, Jeff Rizzo <riz%netbsd.org@localhost> wrote:
>>> On 2/23/15 6:07 PM, Ryota Ozaki wrote:
>>>>
>>>> On Tue, Feb 24, 2015 at 4:00 AM, bch <brad.harder%gmail.com@localhost> wrote:
>>>>>
>>>>> Are there plans (and roadmap?) to user-space dtrace abilities in
>>>>> NetBSD -- currently we're not exporting a certain header (and required
>>>>> code support?) for userland dtrace support; kernel-only, as I
>>>>> understand.
>>>>>
>>>>> Is my understanding correct?
>>>>
>>>> Yes, NetBSD now supports only tracing inside kernel activities.
>>>>
>>>> AFAIK, nobody is working on the user-space support for now.
>>>>
>>>>    ozaki-r
>>>>
>>>>>
>>>
>>> One of the things I learned while hacking on Dtrace is that it's not as
>>> hard
>>> as it looks from the outside ;) - if it's something you're interesting in
>>> seeing, I recommend looking at the FreeBSD and Illumos sources, and a lot
>>> of
>>> it will just Make Sense!
>>
>> Indeed. I'll do that :)
>>
>>   ozaki-r
>>
>>>
>>> Thanks, ozaki-r, for picking this up... I've been very short on time
>>> lately,
>>> and I'd love to see this in.
>>>
>>> +j
>>>
>>