3 ms·
This is an interesting option. Although in our case, our eBPF runs in external customer's environment, and we cannot ask them to patch their kernels with our c
by justicezyx 7y ago
This is an interesting option.
Although in our case, our eBPF runs in external customer's environment, and we cannot ask them to patch their kernels with our code.
- monocasa 7y agoI feel like we're talking on two different levels here. It's sort of like how Oak was this neat virtual machine for running on a early 90s PDA prototype. Then the writers of that VM realized that they had written a really general purpose VM, cleaned it up and released the first Java. This general of a VM (talking about eBPF now) hasn't been a first class citizen of a mainstream kernel before. The devs are taking a very cautious approach (as they should), but ultimately eBPF is way bigger than a tracing tool. I wouldn't be surprised to see nearly everything you currently do with a kernel module ultimately being allowed by eBPF too. Maybe more like emulating other OS's kernels as easily as you'd start another container.
- justicezyx 7y agoAlso different time scale. I am on existing stuff can be readily used. You are probably estimating the future, I guess?