yes. the author of that deck is playing it pretty loose when it come to the definition of a microkernel.
normally the microkernel means the minimum needed primitives to implement the OS and after that everything is build on top of that, not pluggable modules.
For all intents and purposes the Linux kernel is a monolithic one and the eBPF capability make it more extensible / less of a pain to do certain things but definitely do not turn it into a microkernel.
> normally the microkernel means the minimum needed primitives to implement the OS and after that everything is build on top of that
Sure, the minimum amount of full trust code. In this case, the full trust code is the eBPF VM which enforces protection boundaries instead of the MMU as in a classic microkernel. I'm not sure a microkernel classification ought to depend on the MMU specifically, it's a general system design philosophy.
it’s not just the memory protection. it’s the scheduling, IPC, etc.
the eBPF vm uses the capabilities of the kernel, it is not the kernel. No kernel, no nothing.
also, following your train og thought I could say that containers make this a microkernel. it would be a claim that would get you laughed out of a room.
A kernel provides trusted runtime services for an operating system.
A microkernel provides a minimal set of trusted runtime services for an operating system, and relies on some protection mechanism for isolating subsystems to avoid corrupting the trusted core. Preemptive scheduling is not necessarily part of it; depends whether your system requires "time" to be a protected resource.
eBPF is a kernel service, just like processes, scheduling, IPC. If eBPF can isolate subsystems and supports safe collaboration of eBPF programs despite all running at ring 0, then the eBPF VM in the Linux kernel could qualify as a microkernel once you remove everything else.
> also, following your train og thought I could say that containers make this a microkernel.
If you could run all of the device drivers in containers such that they couldn't corrupt the kernel's data, then sure, you could run it as a microkernel because you wouldn't have anything left in the kernel except essential services like threading, IPC and containers.
normally the microkernel means the minimum needed primitives to implement the OS and after that everything is build on top of that, not pluggable modules.
For all intents and purposes the Linux kernel is a monolithic one and the eBPF capability make it more extensible / less of a pain to do certain things but definitely do not turn it into a microkernel.