3 ms·

BPF is awesome. We build a full rust toolchain that targets it https://github.com/solana-labs/rust https://github.com/solana-labs/rust

• roblabla 7y ago
  That looks cool! Any chance it gets upstreamed into rust proper? And if so, is there a place to keep track of that progress?
  • aey 7y ago
    We would love to, maybe in a few months as we stabilize the changes. One challenge is that bpf upstreaming is much harder. We had to add support for relocations, spilling, multiple return values, and a few other things that might not be needed by the C bpf folks.
    • saagarjha 7y ago
      > We had to add support for relocations, spilling, multiple return values, and a few other things that might not be needed by the C bpf folks. I'm curious why C BPF programs wouldn't need this.
      • aey 7y ago
        There is no Linux usecase asking for it. We happen to be using bpf outside of the kernel.
        • saagarjha 7y ago
          Ah, that explains it. To be clearer, I should have probably instead asked why you needed those things ;)
      • uep 7y ago
        I'm a novice at it, but I have written a few small eBPF programs in assembler. To elaborate on what aey said in the sister comment, since eBPF allows user applications to generate code that runs in the kernel, the language is kept pretty simple so that it's easier for the kernel to verify that the generated code isn't doing something bad. If you look at the documentation, there are only two registers: https://www.kernel.org/doc/Documentation/networking/filter.txt https://www.kernel.org/doc/Documentation/networking/filter.t... There are also limitations on the size of eBPF programs the kernel will allow, and looping and such, so that a single user is less likely to DOS the entire system with a bad program (whether purposefully or accidentally). It's not really that similar, but I had the amusing thought that writing eBPF assembly vaguely reminded me a little of writing TIS-100 code. http://www.zachtronics.com/tis-100/ http://www.zachtronics.com/tis-100/