Essence of Linux kernel cultivation (19)-unstable kernel APIs

Recommended blog posts:Linux Kernel "problem Gate"-learning issues and experience highlights

Recommended download:Methodology of essence edition of "Cultivation of Linux kernel"

 

Just now, I was glad to hear that during the trial run of the Sb, the residents of Shanghai visited the site were in a very stable mood and showed their style with great comfort. So here we need to reflect on why kernel APIs cannot be equally stable?

The open-source community is adding new features to the kernel at a very fast speed, and at the same time trying to keep fixing bugs up, slowing down development seems unlikely: first, Linux cannot lag behind in technology, otherwise it will lose business users with increasingly demanding requirements. Second, it is because Linux needs to promote the development of the developer community, and the continuous addition of new features can leave developers bored, otherwise, they may move to other projects and attract new talents when the existing developers are old or quit.

In this fast pace, kernel developers will quickly modify the current interface once they find a bug in the current interface or a better implementation method, which means that, function names may change, struct may be expanded or deleted, and function parameters may also change. Once the interface is modified, the kernel must be corrected at the same time to ensure that all parts continue to work normally.

For example, the USB interface in the kernel has been overwritten at least three times so far, solving the following problems:

Changing the data stream from the synchronous mode to the asynchronous mode reduces the complexity of many drivers and increases the throughput (throughput) of all USB drivers ), the result is that almost all USB devices can work at the maximum rate.

Modified the way to allocate data packet memory from the USB core, so that to solve many deadlock problems, all drivers must provide more parameters to the USB core code.

This is in stark contrast to some operating systems with closed source code. On those operating systems, you have to maintain the old USB interface. This leads to a possibility that new developers will accidentally use the old interface to write code in an inappropriate way, thus affecting the stability of the operating system.

In the above example, all developers agree that these changes are important and have to be made. In this case, the modification cost is very low. If Linux maintains a stable kernel interface, you have to create a new interface, and the old problematic interface must be maintained all the time, this will bring additional work to USB developers. Since all USB developers use their own time to work, it is impossible to ask them to do these meaningless free extra jobs.

Security problems are very important for Linux. If a security problem is discovered, it will be repaired in a very short time. In many cases, this will cause some interfaces in the kernel to be overwritten to fundamentally avoid security issues. Once the kernel interface is overwritten, all drivers using these interfaces must be corrected at the same time to confirm that the security issue has been fixed and that the same security issue may not exist in the future. If the internal interface of the kernel cannot be changed, it is impossible to fix such a security problem or confirm that such a security problem will not occur in the future.

Developers have been cleaning up kernel interfaces. If no one is using an interface, it will be deleted. In this way, we can ensure that the kernel is as small as possible, and all potential interfaces will be tested as full as possible (no one can use the interface to get a good test ).