Designing better kernel ABIs [LWN.net]

Designing better kernel ABIs

Posted Oct 27, 2016 17:16 UTC (Thu) by felixfix (subscriber, #242)
Parent article: Designing better kernel ABIs

Mark new ABIs as beta for one year after introduction by tacking "_beta" onto the end of the syscall name. Fix bugs and stuff as usual, but also feel free to change the ABI spec itself from kernel to kernel, maybe only in major releases (4.1 to 4.2 ok, 4.1.1 to 4.1.2 no).

At the end of that beta period, retain the beta syscall and whatever spec badness is necessary, but fix as much as possible in the non-beta syscall.

One year later, remove the beta syscall.

There would be plenty of howls when the beta syscall did not get the fixes which went into the stable syscall, and probably more when the beta syscall was removed. But you'd be far better off down the road.

to post comments

Designing better kernel ABIs

Posted Oct 28, 2016 4:48 UTC (Fri) by mkerrisk (subscriber, #1978) [Link] (3 responses)

I don't think such schemes would really work. There are many issues there. Many people would treat a Beta marking as "I won't bother even touching this". Others would actually start to depend on the API, and would howl, and exert pressure not to remove the Beta API, and in some cases they might even be successful (and they might even be correct to do so).

In any case, we've effectively done this sort of thing already. There have been cases where _freshly_ released APIs gor removed or changed a kernel release or two later, because it was (correctly) believed to that there would not be many (or, probably, any) users yet. The original timerfd() system call (later made into three system calls) and the paccept() API (later accept4()) are some such cases I recall, having had a hand in the changes. So, we've informally done this sort of thing already, but I don't think it would actually improve matters to formalize the process.

Designing better kernel ABIs - beta release

Posted Oct 29, 2016 23:00 UTC (Sat) by giraffedata (guest, #1954) [Link]

I think having a formal beta test of interface design, by initially naming a system call "xxx_beta" would work. People would use it for the same reason people always participate in beta tests, and even beg to do so: they want the function, and they're willing to pay the price of encountering bugs and having to change their use of it later. Of course, many others would regard it as "don't touch," and that is the point. We don't have to worry about hurting the people who didn't sign up for the risk.

I agree there would always be pressure not to change the beta interface. That is much like where someone designs a product to a draft standard and then argues the draft can't be changed because the product would then not comply. Sometimes they're successful; sometimes they aren't.

The decision to fix a new interface, incompatibly, is always painful. Are there really not many users of it yet? And is it OK to throw those few users under the bus? That decision is much easier when the function has "_beta" in its name and any user is definitely going to have to change his code, if only to call it by its non-beta name, no matter what.

Designing better kernel ABIs

Posted Oct 30, 2016 7:07 UTC (Sun) by dirtyepic (guest, #30178) [Link] (1 responses)

> In any case, we've effectively done this sort of thing already. There have been cases where
> _freshly_ released APIs gor removed or changed a kernel release or two later, because it
> was (correctly) believed to that there would not be many (or, probably, any) users yet.

Well as you say, these problems likely won't surface until someone tries to make use of the API. So, yes, you can change the interface if there aren't significant users but until there's significant users you won't know you need to change the interface.

I don't think adding beta to the call name is a good idea. Just state flat out that APIs are allowed to change for a short time after being introduced, until they are field tested and deemed stable, and that's just something people have to live with. I can't believe that forcing every future user of a system call to have to implement kludgy workarounds for broken behavior or poorly thought out interfaces is preferable to breaking a few things early in its lifetime, especially if that breakage results in an API that is easier to use, more functional, and consistent than it would be otherwise.

Designing better kernel ABIs

Posted Oct 30, 2016 14:58 UTC (Sun) by felixfix (subscriber, #242) [Link]

You say "Just state flat out that APIs are allowed to change for a short time after being introduced." The problem is knowing what "a short time after being introduced" is. If someone doesn't follow kernel changes much, they may have no idea how new or old an API is. That's one point of tacking "_beta" on the end -- it tells people right up front that this is new.

I also don't see much of a drawback to editing programs to remove the "_beta" a year later. Any program which never needs to be edited again is probably not being used much, so it's just a tiny edit if the API hasn't changed, or has only changed in trivial ways. If the beta interface was found lacking and needed major changes, then the beta callers need to revisit the API anyway.

Designing better kernel ABIs

Posted Nov 5, 2016 0:24 UTC (Sat) by Zolko (guest, #99166) [Link]

Mark new ABIs as beta for one year

wasn't this the whole point of the stable and development branches in the kernel naming ? Stable meaning "stable ABI" and development meaning "changing ABI" ?