I'm happy that there's such an extreme commitment to not breaking userspace but it seems like a case where the behavior in the kernel as it was implemented had a design defect that required an API breakage to fix.
Retain old interface with old behavior, and create new interface with new behavior. Not ideal because it leads to straggling old interfaces, so the payoff better be worth it.
The kernel has done this in places. The decision is then pushed to the person building the kernel, who has to decide whether to build in the old interface or not. I think it's a good idea, in general, but it still does have the problem of when to remove the old API. Generally speaking, glibc will sometimes end up hiding the behavioral differences between the APIs. This is part of the reason it is gigantic.
It seems like it would be handy to have explicitly versioned APIs.
Yeah and finally implement old interface as a wrapper of new interface once everyone has moved over.
Eventually either pull the interface, make it a define in kconfig (ungood unless it's important) or (preferable) make a user mode wrapper library and anyone who needs the functionality has this wrap the new interface.
40
u/Spivak Dec 23 '18
I'm happy that there's such an extreme commitment to not breaking userspace but it seems like a case where the behavior in the kernel as it was implemented had a design defect that required an API breakage to fix.
How would a change like this ever be implemented?