Why now, and why DTrace (vs BPF)? Looking at the doc [1]:
> Check that you are running a supported version of Windows. The current download of DTrace is supported in the Insider builds of 20H1 Windows after version 18980 and Windows Server Build 18975. Installing this version of DTrace on older versions of Windows can lead to system instability and is not recommended. The archived version of DTrace for 19H1 is available at Archived Download DTrace on Windows. Note that this version of DTrace is no longer supported.
So it's not "now", but has been there for a while. Also it might not be very helpful to align with BPF anyway as the kernel itself is totally different thus any tool reuse wouldn't be very practical.
It probably helps that OpenDTrace has a published specification that you can use to not only to reimplement bits of DTrace from scratch but also to agree on a common behavior across many operating systems: https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-924.pdf
You made me realize that Windows does supprot BPF! I saw that before but forgot about that. Thanks for the reminder! Such a crazy operating system (an applause.)
Why? Because dtrace is portable, has been ported to all major OS, and safe, and has a lot of bindings in a lot of apps and libs already. It seemlessly integrates kernel and Userland calls.
whilst eBPF is Linux only, and completely insecure. with almost none existing userland bindings.
eBPF is not Linux only. Windows is investing into integrating it to their OS and some efforts have begun applying it to the BSDs. There's even a recent initiative to standardize the eBPF runtime.
eBPF can work with Dtrace's USDTs as well as dynamic u(ret)probes.
Yours doesn't even support the D language, which is the most useful part of DTrace.
Also it lacks the most important property of DTrace -- safety. With DTrace you can't crash the machine. Unless I am misunderstanding something, your code doesn't have this property.
Yes, you do misunderstand. The D language is terrible, it has no loops, no functions, it is not a usable language beyond basic scripts. The _good_ part of the windows implementation is the kernel interfaces, which is what my design uses. The entire point of this research was to discard the D language.
My implementation(s) allow you to use C++ 17, or Web Assembly instead. These are significantly more powerful languages. The Web Assembly scripts are a demonstration of using the same 'safe' architecture as DTrace. While the C++17 DLL system is a demonstration of an 'unsafe' but more powerful design.
If you think DTrace can't crash the system, you are mistaken.
I appreciate that you feel you are solving a problem, but you are in fact solving a different problem than DTrace was designed to solve -- and what you perceive to be "terrible" aspects of D are in fact deliberate design decisions to abide by DTrace's safety constraint.[0]
I am aware of the differences. My goal was not to recreate dtrace 1 to 1, it was to extend it with trade-offs. I've heard the argument made many times, my system is not meant to be deployed on end point user systems. A recreation obeying the same constraints of dtrace could be constructed, it would simply involve swapping the scripting system for another.
If your argument is that loops are unsafe, please go look at ebpf, which has loops. If you think user defined functions are unsafe, go look at ebpf again - it's nearly C. If your argument is shipping code from user to kernel is unsafe, go look at ebpf byte code, I could easily implement signing to validate only trusted plugins can load.
Your argument is close minded. These are trade-offs, and can be easily changed to obey different constraints. My system open sources previously undocumented kernel interfaces. If you dislike the constraints I chose, fork it and go rebuild dtrace exactly, it's not that I'm not solving a real problem - I'm just solving one you fail to understand.
We agree! I'm not calling dtrace bad for the record, it's awesome. My issue is just with the language users are forced to write in not being expressive enough (specifically on windows at that). If fixed length loops and user defined functions were added, it would be quite a lot easier to implement advanced scripts.
Example from the doc. Probes not being allowed to call other system routines to avoid reentrancy. Dtrace avoids this architecturally, as your link says. I disliked this, so I chose the alternative, which so happens to be mentioned in the same document. My system detects reentrancy and avoided calling probes when it's determined the caller was itself a probe.
I simply chose different constraints. It 'not being secure' is a facade. It's not meant to be, I could make it so though, if I wanted to. I bothered with the entire rust + wasm implementation specifically to show that this argument of not being secure' because I didn't use the D language was untrue. Browsers themselves execute untrusted code via wasm. If the concern is the halting problem, then just use wasm with bounded loops.
Last commit 4 months ago... and then a year ago... and then two years before that.
I saw this mentioned here a while back and saw the "last commit 2 years ago" status in GitHub and just ignored it completely. It's most likely someone's pet project with no real support in the larger Microsoft corp.
Oh and I tried it in a virtual machine, but it just blue screened, which doesn't inspire confidence.
I am getting the same feeling, as Microsoft's track record with such things hasn't been stellar, anyway.
A crucial point, however, is that Windows Server only has had a kernel new enough to support this for a little while (not counting previews and RCs for obvious reasons), which I'd say is the one Microsoft platform that would benefit the most from this.
Also, since it's really hard for outsiders to find documentation on Windows kernel interna (which means as a normal user you'd be tracing syscalls at best), I suspect a key motivation was to improve observability for the Windows dev team, so we possibly also wouldn't be able to estimate of how much use the port really is.
Windows since Vista actually has a similar tool called ETW that is insanely powerful and worth a look as well. It also has its own analyzer tool called XPerf to help you understand the data you capture.
ETW is not similar at all to DTrace, a fact explained in the README of the linked repository.
I am not privy to Microsoft's decision to port (and ship!) DTrace to Windows, but I would imagine its advantages compared to ETW had something to do with it...
It is similar in the types of problems you would try to solve with both tools, and the data that you can collect - not in their design. Both allow you to gather extremely detailed performance and trace information about a running system, without having to explicitly stop/restart running processes.
> without having to explicitly stop/restart running processes.
With DTrace you not only don't have to restart processes, but you don't have to recompile them. ETW is glorified logging. Logging is useful, but dynamic tracing is transformatively different. I can't recompile the Windows kernel to add missing ETW probes, but I can use DTrace to probe it just fine.
Where do you guys learn about using eBPF? It’d be really useful for my work, I think, but then most intros I see start with ‘Recompile the Linux distro’ or something and that just seems too much effort to get going?
Contrary to the title, I would actually recommend the first one more and only if you feel starved for more to reach for the second one. You can learn a lot about performance tools and methodologies on Linux from the first one, not just eBPF.
I've never had to recompile a Linux distro to start using eBPF btw. Most distros already use a kernel compiled with options enabling eBPF. That may not be true on some "embedded Linux" devices though.
My impression is that on open-source operating systems, some of DTrace's / eBPF's value lies in the ability to monitor kernel internals.
If that's true, is DTrace as valuable on Windows, where computer owners don't have access to the OS's source code?
For example, I'd love to use a tool like DTrace to monitor if/when/what telemetry data is being gathered and sent to Microsoft. But I imagine that's not possible for regular people like me.
> Check that you are running a supported version of Windows. The current download of DTrace is supported in the Insider builds of 20H1 Windows after version 18980 and Windows Server Build 18975. Installing this version of DTrace on older versions of Windows can lead to system instability and is not recommended. The archived version of DTrace for 19H1 is available at Archived Download DTrace on Windows. Note that this version of DTrace is no longer supported.
So it's not "now", but has been there for a while. Also it might not be very helpful to align with BPF anyway as the kernel itself is totally different thus any tool reuse wouldn't be very practical.
[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/de...