goombacloud

8 ms·

61.
by goombacloud 5y ago
I hope someone also picks up the work started in https://project-oak.github.io/rust-verification-tools/ - the idea of having a `cargo verify` tool that supports different backends is great for bridging the academic PoC
62.
by goombacloud 5y ago
You lose the regular Linux process you are used to and the interaction you can have between processes: start new ones to offload a small task, pipe data, trace them with strace or debug them with gdb. I think this convenience also held back
63.
by goombacloud 5y ago
Offloading to the NIC is of course the fastest way but even doing it in the NIC driver (check if the NIC driver supports it or you have to use the slower generic fallback) you already have advantages similar to doing it with DPDK.
64.
by goombacloud 5y ago
Depending on the requirements of the RPC you could implement the logic in eBPF code over the XDP framework which can directly execute the code inside the NIC driver and modify the packet buffer to be a response packet that gets send out imm
65.
by goombacloud 5y ago
A question to you as someone from the hardware side: Why is it not a focus for hardware devs to build hardware that works with existing software? Why do I always need a special kernel for every arm64 board out there? Often it's that th
66.
by goombacloud 5y ago
Still needs to spawn a temporary process but it can be killed early: true | sleep infinity & STDINPID="$!" exec {mypipe}<"/proc/$STDINPID/fd/0" # hijack FD TMPPIPE="/proc&#x
67.
by goombacloud 5y ago
One more fun experiment: avoid the tempfile on disk/tmpfs by storing data into the pipe connecting two processes, where the first one can already exit for the pipe to give EOF when reading beyond the buffered data. true | sleep inf
68.
by goombacloud 5y ago
To spare you the trap you can open the file as FD in your bash process (e.g., exec {my_fd}>"$TMPFILE") and then directly delete it before doing anything else, and use the /proc handle to access it ("/proc/$$