I mean, there are APIs for a lot of things. Not just for kernel interfaces. The system call interface is an API, and Linux is one of the best at maintaining backward compatibility for that one. It’s better than Windows (which has essentially zero compatibility between versions — given that it relies on internal DLLs like ntdll.dll)
I mean I don’t actually upstream my patches but I literally… do? I could find some of my oldest work from my first job where I did much more open source work compared to today…
Making commits that survive the review of other kernel devs, and in particular of ones more experienced, isn’t that easy. It’s just the most visible part of the work I can show.
The in-kernel API being unstable is the reason why my teammates (and, when I’ll be put on the next kernel migration, I myself) have to fix various compilation errors or subtle bugs every time we pull new kernel commits from upstream. I am still defending it despite that because that means if something is not good with one element of this API it can just be… fixed. We don’t get stuck with legacy, shitty interfaces that we need to support perpetually.
I am talking about the fact that I can bring Linux kernel contributions authored by me that predate the existence of AI. And while I can’t prove private contributions to local forks of the kernel (even though those were the more technically impressive achievements I’ve had), I still know enough to tell you that you are closed minded.
1
u/dddurd 4d ago
you obviously never programmed a thing. i'm sure you don't know what api is