Some of the Linux kernel's more fundamental APIs can be quite old, and some of them have been written in the "Wild West" era of the project. Naturally, such an API can accumulate hundreds, sometimes thousands of users. Some APIs haven't been cleanly designed from start to finish, but have grown steadily as the need arose, being written by several authors. Some ended up being used differently than expected.

Should it later be discovered that the API or its internals have minor or major issues, it cannot be changed anymore without simultaneously changing all the API users across dozens of subsystems, involving dozens of maintainers.

This implies that touching such an API is not only a technological topic, but also involves a good share of "kernel politics": you need to convince maintainers, partition your changes across several kernel releases, figure out a merge plan etc.

This talk is about such an API improvement process in the PCI subsystem, code for a bus that a lot of drivers rely on. We shall look into the following aspects: - How do you know that the honorable old API, and not you, is the problem? - Build a strategy to slowly phase the problem out, step-by-step over several kernel releases - By being very careful, of course we'll ensure that nothing will explode! - ... but things will explode anyways. What then? - Maintainer relations 101: How to help the maintainer to easily merge your changes