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
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.
to post comments)