<peter.waskiewicz.jr@...> wrote: I expect to use BTF as a source for kernel struct information, as a lightweight version of debuginfo (and hopefully one day BTF info will be included in the kern

I'm ok with the workaround code, but I'd like a comment that clearly explains it for future maintainers and copy-n-pasters. Eg: // Skip entries with backwards time: temp workaround for #728 Then peopl

G'Day, We've been working on wrapping up bpftrace for a while -- a high-level tracer for eBPF -- and we've now made the private repo public: https://github.com/iovisor/bpftrace Thanks Alastair Roberts

Tools look excellent, thanks! When you're ready, could you submit as a github bcc PR? thanks, Brendan

G'Day Evgenii, As in CONTRIBUTING_SCRIPTS.md, we're after tools that do one thing and do it well, so I'd generally avoid adding features that didn't belong in tools. In this case, it might actually be

C_INCLUDE_PATH=... environment variable should work. But you can file an RFE or PR anyway to add this to the docs. Thanks! Brendan

The stack ID returned by ustack() points to a stack as a list of addresses. That gets translated sometime later in user-space by bpftrace. At that point you just have an address, and you need to know

Following on from the call... Does this sound even better? (mapping from the JVM for comparison): The JVM is a specification of a virtual machine that runs Java bytecode. It is implemented by a Java R

G'Day, This is the biggest change afoot to the bpftrace API, and I think we can sort it out quickly without fuss, but it is worth sharing here. This is from https://github.com/iovisor/bpftrace/issues/

G'Day, Many of you already know (and have been helping, thanks) and we've discussed this on the iovisor call before: my book is finally launched properly. Some URLs: http://www.brendangregg.com/blog/2

^^^^ sudo isn't safe. If you remove the BCC tool from this one-liner, you'll find it still destroys your disk. In practice the production concern I have is for the overhead of each tool, hence the ove

G'Day all, I have colleagues working on BCC Python tools (e.g., the recent enhancement of tcpconnect.py) and I'm wondering, given libbpf tools, what our advice should be. - Should we keep both Python