Oniro ABI and API checker
In an OS distribution where the OS might be open source and built from sources, but the applications can be binary e.g. downloaded from an app store, the OS API and ABI needs to be maintained unchanged for the life of a particular OS version, through its various updates. Otherwise API changes in underlying libraries or ABI changes due to changes in the way the compiler generates code could break the applications running on the system.
A distribution needs to manage its API and ABI interfaces to ensure compatibility with binary applications and modules after software updates are applied. This is a basic requirement in an environment where the OS might be open source and built from sources, but the applications can be binary e.g. downloaded from an app store.
API changes happen when libraries change their list of publicly exported functions in some way: either by removing existing functions or changing the function signature that then requires any application using that library to be fixed to replace the old function or update the parameters to the new signature.
ABI contracts involve the compiler, linker and kernel running on a particular HW architecture. If the compiler changes how binaries are compiled (e.g. by changing how paramaters are passed to functions (via registers or the stack or a combination), where the return value of a function is placed, etc.) it will break ABI compatibility with applications compiled with the old version of the compiler. Similarly, if data structures are changed so that it affects their alignment, it will affect any code accessing that data using the old data structure layout. Additionally, the kernel's system call interface is the interface it provides to userspace. If compiler or data structure changes somehow change how these functions can be used, older userspace applications will no longer be able to use a kernel with these changes.
So Oniro needs to maintain a stable API and ABI during the lifetime of a release. This means that any bug fixes and CVEs will need to be checked for API/ABI changes before they are released publicly. This can be done with some automated tools that keep track of public function signatures from one maintenance release to next and flags any changes.
Some existing tools to investigate when building our ABI and API checkers include:
- Example usage
- AOSP abi checks
- Upstream tracker
- Sanity checker to automatically generate tests cases from analysis of header files
- ABI checks performed on the Ubuntu kernel
We might need to have different levels of API and ABI promises for different packages. See RHEL example. The checker will help us create multiple whitelist of packages at different levels for which we support API/ABI stability.
Out of Scope
- Writing new abi tools. Focus is on integration and contributing to existing upstream projects.
- A set of tools that checks the API and ABI at various levels:
- Kernel interfaces
- C library interface
- Interface for
core platformlibraries. See
In Scopesection above.
- Compiler abi check
- Integration of tools into CI pipeline
- Integration into CI to check for breaking API/ABI to fail the build and alert the maintenance team