A new way of ordering kernel initialization [LWN.net]

The Linux kernel is made up of a very large number of mostly independent modules. In general, these modules can be linked together and initialized (at boot time) in any order. There are cases, however, where initialization order matters. The memory management system generally needs to be set up early in the process, filesystems generally need a functioning block system to be ready first, etc. Some years ago, initialization order was handled with a big set of explicit calls in a single source file. This big file inhibited modularization and created a clash point for patches, and it was (mostly) eliminated some time ago.

The current scheme involves marking initialization functions with variants of the initcall attribute. At link time, these functions are marshalled together into a special section of the kernel executable; the kernel finds them there at boot time and calls them all. As an added bonus, the initialization calls can generally be flushed out of memory once initialization is complete.

This scheme is far more modular and easy to maintain, but the initialization order problem remains. In recent times that problem has been handled through a combination of hardwired calls and variants on the initcall macro. So, subsystems whose initialization calls are marked with core_initcall are initialized before those using, say, fs_initcall. These macros give a coarse solution to the problem, but initialization order problems can still show up.

Now Rusty Russell has posted a new mechanism which allows kernel hackers to make initialization dependencies explicit. If driver1 must be set up before driver2 can be initialized, driver2 can simply mark its initialization call as:

    initcall (driver2_init, driver2, init_after(driver1));

There is also an init_before marker, of course, along with init_as_part_of for complicated subsystems. A new build_initcalls script has the job of sorting out the dependencies and creating an ordered list at kernel build time. The patch looks simple and straightforward; initialization order problems could soon be a thing of the past.