4 ms·
In Linux’s defense, the userland abi is stable, which is no small feat in terms of absorbing pain in order to benefit their many users.. Not sure why the trade
by beng-nl 1y ago
In Linux’s defense, the userland abi is stable, which is no small feat in terms of absorbing pain in order to benefit their many users..
Not sure why the trade-off consideration led to a different outcome for in-kernel api’s, but given the work done to ensure the stability of the userland abi, I’m sure there is thought behind it..
- musicale 1y ago> userland abi is stable The system call interface per se is relatively stable. Then there's all that stuff that has been dumped into /proc...
- DSMan195276 1y agoWell from a certain POV it's like stabilizing APIs internal to your application - nobody else should be calling them so "stabilizing" them just creates unnecessary maintenance work. Obviously in practice certain things like eBPF or externally-maintained drivers can break this model, but then they don't really want people doing those things vs. merging code into the kernel.
- alexjplant 1y ago> In Linux’s defense, the userland abi is stable, which is no small feat in terms of absorbing pain in order to benefit their many users.. I understand that technically eBPF programs run on a VM in kernel space but aren't they loaded from userspace? Isn't eBPF an alternative to developing kernel modules and in-tree drivers? To a layperson like me it walks, talks, and quacks like userspace much more than the kernel. The fact that struct layout can change at the whim of kernel developers seems counterproductive. I guess this is what CO-RE is supposed to solve but having to deal with a bunch of pointer and sizeof() chicanery seems archaic (coming from a total luser/kernel nublet that hasn't written C in over a decade).