The Linux kernel-user-space API is littered with design errors: APIs that are non-extensibe, unmaintainable, overly complex, limited-purpose, violations of standards, and inconsistent. Most of those mistakes can't be fixed because doing so would break the ABI that the kernel presents to user-space binaries. To further rub salt into the wound, kernel-user-space APIs are often buggy when first shipped. Thus, it's important to get API designs right the first time. Taking (good and bad) examples from past APIs, I'll cover a number ideas on improving the design of future kernel user-space APIs. Those tips are relevant both for kernel developers producing the APIs and for user-space programmers looking at what kernel developers are serving to them. I'll also look at some strategies that developers can pursue in order to get help with improving the designs of APIs that they are producing.

The Linux kernel-user-space API is littered with design errors: APIs that are non-extensibe, unmaintainable, overly complex, limited-purpose, violations of standards, and inconsistent. Most of those mistakes can't be fixed because doing so would break the ABI that the kernel presents to user-space binaries. To further rub salt into the wound, kernel-user-space APIs are often buggy when first shipped. Thus, it's important to get API designs right the first time. Taking (good and bad) examples from past APIs, I'll cover a number ideas on improving the design of future kernel user-space APIs. Those tips are relevant both for kernel developers producing the APIs and for user-space programmers looking at what kernel developers are serving to them. I'll also look at some strategies that developers can pursue in order to get help with improving the designs of APIs that they are producing.

Audience

The intended audience is kernel developers and user-space programmers with an interest in the long-term health of the kernel-user-space API, as well as anyone with an interest in API design.