5 ms·

I was a little disappointed DTrace[0] was not mentioned at all. The instrumentation (not the SDN) isn’t novel, not even to Linux (DTrace is available on Linux -

by bch 3y ago

I was a little disappointed DTrace[0] was not mentioned at all. The instrumentation (not the SDN) isn’t novel, not even to Linux (DTrace is available on Linux - I understand licensing is at least questionable (for some distros), but that aside…). [1] [0] https://en.wikipedia.org/wiki/DTrace https://en.wikipedia.org/wiki/DTrace [1] https://docs.oracle.com/en/operating-systems/oracle-linux/dtrace-tutorial/dtrace-tutorial-IntroducingDTrace.html https://docs.oracle.com/en/operating-systems/oracle-linux/dt...

kragen 3y ago
i feel like the fact that the page mentions brendan gregg is a pretty strong reference to dtrace already. actually it doesn't just mention him, it's completely written by him
- bch 3y ago
  I think people that know, know he was involved (in the userland aspect) of DTrace, but I get a sense for some reason there’s no love lost between Brendan and “DTrace”.
ta8645 3y ago
DTrace was not the inspiration for eBPF at all, so it's not obvious it is relevant to mention. As the documentary mentions, the initial impetus for eBPF, was software defined networking. eBPF is a much bigger and more comprehensive infrastructure piece (networking, tracing, security, etc) than DTrace. And thanks to licensing issues, even within the limited domain of tracing, DTrace will likely become a footnote in history, while eBPF becomes available on every major OS platform.
- bcantrill 3y ago
  There aren't "licensing issues" with DTrace -- you are merely referring to the fact that it is licensed under the MPL-derived CDDL and not the GPL. But it is definitely true that they are not seeking to solve the same problems! Safety is very core to DTrace[0]; the difference here is entirely deliberate. [0] https://bcantrill.dtrace.org/2005/07/19/dtrace-safety/ https://bcantrill.dtrace.org/2005/07/19/dtrace-safety/
  - ta8645 3y ago
    AFAIU, it goes beyond safety; eBPF is designed to run entirely in the kernel rather than requiring a user-space bridge. So it's able to operate at line speeds in networking scenarios etc. > you are merely referring to the fact that it is licensed under the MPL-derived CDDL and not the GPL. Not really. I'm referring to the fact the eBPF will be available across Microsoft, Apple, and Linux, and there is no other technology that will be able to offer that. > not seeking to solve the same problems! Exactly. eBPF has a much broader and more significant problem set, not just tracing, but also security modules, software defined networking, and an almost unlimited future potential as well.
    - bcantrill 3y ago
      A few points of clarification: - DTrace does execute entirely in the kernel. Indeed, anonymous tracing is instrumenting the system without any corresponding user process whatsoever - DTrace exists on quite a few systems, including (with caveats) Windows, MacOS and Linux. - The unbounded nature of eBPF very much runs contrary to the safety that DTrace assures; DTrace isn't seeking to augment the system, but merely to understand it
      - tdullien 3y ago
        eBPF has only recently become less bounded, at 4.15 for example it was still very bounded ;). (I assume you mean maximum # of instructions etc?)
    - bch 3y ago
      > I'm referring to the fact the eBPF will be available across Microsoft, Apple, and Linux, and there is no other technology that will be able to offer that. I don’t know if there’s some qualification I’m missing in your statement, but does this not count? https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/dtrace https://learn.microsoft.com/en-us/windows-hardware/drivers/d... https://opensource.apple.com/source/dtrace/ https://opensource.apple.com/source/dtrace/ https://docs.freebsd.org/en/books/handbook/dtrace/ https://docs.freebsd.org/en/books/handbook/dtrace/ https://github.com/dtrace4linux/linux https://github.com/dtrace4linux/linux
deleted 3y ago
[deleted]
monocasa 3y ago
AFAICT DTrace is more a parallel branch. Both inspired by cBPF. What should get more talk IMO, is the exokernel XOK's kernel VMs which went way harder than even eBPF does towards user space programmability for the kernel as a core primitive. For instance instead of sleep(2) or futex(2) calls, XOK exposed "wake programs" that user space would register for the scheduler to run to answer "is this blocked thread runnable again". Would have solved the collabra's need to change futex(2) to work more nicely with wine/windows primitives in a more general way.

by bch 3y ago

kragen 3y ago

i feel like the fact that the page mentions brendan gregg is a pretty strong reference to dtrace already. actually it doesn't just mention him, it's completely written by him

bch 3y ago
I think people that know, know he was involved (in the userland aspect) of DTrace, but I get a sense for some reason there’s no love lost between Brendan and “DTrace”.

ta8645 3y ago

DTrace was not the inspiration for eBPF at all, so it's not obvious it is relevant to mention. As the documentary mentions, the initial impetus for eBPF, was software defined networking. eBPF is a much bigger and more comprehensive infrastructure piece (networking, tracing, security, etc) than DTrace. And thanks to licensing issues, even within the limited domain of tracing, DTrace will likely become a footnote in history, while eBPF becomes available on every major OS platform.

bcantrill 3y ago
There aren't "licensing issues" with DTrace -- you are merely referring to the fact that it is licensed under the MPL-derived CDDL and not the GPL. But it is definitely true that they are not seeking to solve the same problems! Safety is very core to DTrace[0]; the difference here is entirely deliberate. [0] https://bcantrill.dtrace.org/2005/07/19/dtrace-safety/ https://bcantrill.dtrace.org/2005/07/19/dtrace-safety/
- ta8645 3y ago
  AFAIU, it goes beyond safety; eBPF is designed to run entirely in the kernel rather than requiring a user-space bridge. So it's able to operate at line speeds in networking scenarios etc. > you are merely referring to the fact that it is licensed under the MPL-derived CDDL and not the GPL. Not really. I'm referring to the fact the eBPF will be available across Microsoft, Apple, and Linux, and there is no other technology that will be able to offer that. > not seeking to solve the same problems! Exactly. eBPF has a much broader and more significant problem set, not just tracing, but also security modules, software defined networking, and an almost unlimited future potential as well.
  - bcantrill 3y ago
    A few points of clarification: - DTrace does execute entirely in the kernel. Indeed, anonymous tracing is instrumenting the system without any corresponding user process whatsoever - DTrace exists on quite a few systems, including (with caveats) Windows, MacOS and Linux. - The unbounded nature of eBPF very much runs contrary to the safety that DTrace assures; DTrace isn't seeking to augment the system, but merely to understand it
    - tdullien 3y ago
      eBPF has only recently become less bounded, at 4.15 for example it was still very bounded ;). (I assume you mean maximum # of instructions etc?)
  - bch 3y ago
    > I'm referring to the fact the eBPF will be available across Microsoft, Apple, and Linux, and there is no other technology that will be able to offer that. I don’t know if there’s some qualification I’m missing in your statement, but does this not count? https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/dtrace https://learn.microsoft.com/en-us/windows-hardware/drivers/d... https://opensource.apple.com/source/dtrace/ https://opensource.apple.com/source/dtrace/ https://docs.freebsd.org/en/books/handbook/dtrace/ https://docs.freebsd.org/en/books/handbook/dtrace/ https://github.com/dtrace4linux/linux https://github.com/dtrace4linux/linux

deleted 3y ago

[deleted]

monocasa 3y ago

AFAICT DTrace is more a parallel branch. Both inspired by cBPF. What should get more talk IMO, is the exokernel XOK's kernel VMs which went way harder than even eBPF does towards user space programmability for the kernel as a core primitive. For instance instead of sleep(2) or futex(2) calls, XOK exposed "wake programs" that user space would register for the scheduler to run to answer "is this blocked thread runnable again". Would have solved the collabra's need to change futex(2) to work more nicely with wine/windows primitives in a more general way.