KS2008: Cross-subsystem interactions

By Jonathan Corbet
September 16, 2008

LWN's 2008 Kernel Summit coverage

Jean Delvare has an interesting job: he is the maintainer of the i2c subsystem. Most users don't think much about i2c devices, but kernel developers involved with a number of subsystems are well aware of them. For example, a webcam driver is often three drivers internally: one for the camera controller, one for the camera itself, and one for the i2c connection which allows the host system to configure the camera. There are i2c buses lurking within a number of other devices, so the i2c layer pops up in a number of places. Thus, changes to the i2c layer affect quite a few developers in other parts of the kernel.

Jean talked about some of the lessons he has learned over the years. It is necessary to cleanly separate the subsystems. In each case, developers need to know the subsystems their code works with and the associated maintainers; that knowledge will make it much easier to get changes accepted. All subsystems should be treated equally, and subsystem maintainers should be warned about changes as early as possible. It is best to work with those maintainers to chart out a path which makes the changes as easy as possible for everybody to deal with.

So where do the problems come in? The universal answer was API changes, especially when there are disagreements over how an API should look. Linus pointed out that disagreements often come about when the maintainership boundaries are unclear. There is, for example, a lot of architecture-specific code which is essentially part of the PCI layer, leading to conflicts between architecture and PCI maintainers. Sometimes the only real solution is to refactor the code - not a simple or quick process.

Nick Piggin talked about problems getting maintainers to accept new APIs. Part of his difficulty seems to stem from his idea that, when an API needs to change, the maintainers of affected subsystems should do the work of adjusting to the change. Strangely enough, people tend to react poorly when others create more work for them. Still, Nick would like subsystem maintainers to help out when an API change needs to happen. A developer who fixes a buggy API should be rewarded; forcing that developer to fix all users of the affected API seems, instead, like punishment.

Linus disagreed with that reasoning, though. He noted that there is a lot of code in the kernel which is effectively unmaintained; there is nobody else who can take on the work of fixing it when an API changes. And, he says, some developers are far too eager to make API changes. Anything which causes them to hesitate, and to maybe think about how to minimize the pain caused by the change, is a good thing.

There were no real conclusions from this session; having said their piece, the developers moved on to the next topic.