I don't think that word means what you think it means.<p>Microkernel = move all the code OUT OF the kernel.<p>These slides are about moving all the code INTO the kernel.<p>Putting your application logic into the kernel would be more like a unikernel I guess?
I'm not seeing how this helps solve the API stability problem faced by ordinary kernel modules. There must be some difference between this project, and a project that simply creates a more stable wrapper/subset of the APIs available to kernel modules, but it's not clear to me what it is.<p>Also, why use JIT rather than offline verification and ahead-of-time compilation?<p>Aside: the idea that the web delivers on the requirement of <i>Programmability must be provided with minimal overhead</i> is pretty laughable. Think Microsoft Teams (a chat application) would consume 600MB of memory if it were built with C++ rather than Electron? I realise not every JIT-powered technology needs to be as bloated as the web, but it seems a poor example.
While the sites are interesting and Linux gets some functionalities known mostly from micro kennels it's not really turning Linux into a micro kennel at all.<p>It just provided a new _additional_ extension mechanism which is sandboxed and much nicer to use.<p>But to make the Linux kennel into a micro kennel eBPF would need to have the capability to replace _all_ existing kernel modules. Including file system drivers, and graphic drivers. Which is not something it's cable of sand at least currently it's only meant for new kennel functionality in to of the "core" which we have.<p>This maybe could change at some point in the (not very close by) future. But for now it doesn't yet turn Linux into a micro kennel.
The link should be changed to<p><a href="https://docs.google.com/presentation/d/1AcB4x7JCWET0ysDr0gsX-EIdQSTyBtmi6OAW7bE0jm0/preview" rel="nofollow">https://docs.google.com/presentation/d/1AcB4x7JCWET0ysDr0gsX...</a><p>currently it links to the 2nd to last slide and not the beginning.
eBPF is turning Linux into a microkernel like drinking Gatorade is turning me into a Super Bowl quarterback.<p>(I tried to localise this for a predominantly US audience.)
EBPF is ridiculously awesome. It’s safe enough to jit in ring-0!<p>We built a rust tool chain that can output ebpf elfs :). <a href="https://github.com/solana-labs/rust-bpf-builder" rel="nofollow">https://github.com/solana-labs/rust-bpf-builder</a>
EBPF is a super interesting technology but it’s so painfully hard to use it for application development. There are some tools based on LLVM to compile EBPF programs using C as a source language (which is much easier to reason in than the low-level code), but there is a lot of room for improving the developer workflow.
I don't see anyone sharing it, but the video for this talk is here: <a href="https://www.infoq.com/presentations/facebook-google-bpf-linux-kernel/?utm_source=twitter&utm_medium=link&utm_campaign=helpcampaign" rel="nofollow">https://www.infoq.com/presentations/facebook-google-bpf-linu...</a>
eBPF are vendor kernel modules on steroids: now instead of getting compile failures trying to build your out-of-tree module, your stuff just blows up at runtime.
Everything would be a microkernel if adding some kind of VM or interpreter is enough to get that name, no?<p>With that logic, could we argue loadable kernel modules (perhaps with proper memory separation) are a sign of a microkernel architecture?
It's turning it into an exokernel.<p>Check out xok, it had three in kernel virtual machines.<p><a href="https://github.com/monocasa/exopc/tree/master/sys" rel="nofollow">https://github.com/monocasa/exopc/tree/master/sys</a>
I was thinking as EBPF as a way to enter in the Linux kernel development with a modern language, but I'm kinda confused by I read in the comments, it's not quite a thing?
"A thorough introduction to eBPF"<p><a href="https://lwn.net/Articles/740157/" rel="nofollow">https://lwn.net/Articles/740157/</a><p>Excerpts:<p>"While eBPF was originally used for network packet filtering, it turns out that running user-space code inside a sanity-checking virtual machine is a powerful tool for kernel developers and production engineers."<p>[...]<p>"The eBPF virtual machine more closely resembles contemporary processors, allowing eBPF instructions to be mapped more closely to the hardware ISA for improved performance."<p>[...]<p>"Originally, eBPF was only used internally by the kernel and cBPF programs were translated seamlessly under the hood. But with commit daedfb22451d in 2014, the eBPF virtual machine was exposed directly to user space."<p>[...]<p>"What can you do with eBPF?<p>An eBPF program is "attached" to a designated code path in the kernel. When the code path is traversed, any attached eBPF programs are executed. Given its origin, eBPF is especially suited to writing network programs and it's possible to write programs that attach to a network socket to filter traffic, to classify traffic, and to run network classifier actions. It's even possible to modify the settings of an established network socket with an eBPF program. The XDP project, in particular, uses eBPF to do high-performance packet processing by running eBPF programs at the lowest level of the network stack, immediately after a packet is received.<p>Another type of filtering performed by the kernel is restricting which system calls a process can use. This is done with seccomp BPF.<p>eBPF is also useful for debugging the kernel and carrying out performance analysis; programs can be attached to tracepoints, kprobes, and perf events. Because eBPF programs can access kernel data structures, developers can write and test new debugging code without having to recompile the kernel. The implications are obvious for busy engineers debugging issues on live, running systems. It's even possible to use eBPF to debug user-space programs by using Userland Statically Defined Tracepoints."<p>There, now you understand eBPF.<p>It is not a Microkernel.<p>It is an in-kernel Virtual Machine, with access to all of the kernel, whose programs can register for, receive, filter, and optionally act upon or act to moderate, kernel events.<p>Quite the powerful tool indeed -- but not a Microkernel...
> Rebooting 20,000 servers takes a very long time without risking extensive downtime.<p>With eBPF, hot-patching servers will take a very short time to start the extensive downtime, plus the consequent reboot of 20,000 servers.