On Sat, Oct 17, 2015 at 07:14:13PM +0200, Alexander Holler wrote: > Hello, > > here is the newest version of my patches to use a dependency based > initialization order. It now works without DT too. > > Background: > > Currently initcalls are ordered by some levels and the link order. This > means whenever a file is renamed, changes directory or a Makefile is > modified the order with which initcalls are called might change. This > might result in problems. Furthermore, the required dependencies are > often not documented, sometimes there are comments in the source or in a > commit message, but most often the knowledge why a specific initcall > belongs to a specific initcall level isn't obvious without carefully > examing he source. And initcalls are used by drivers and subsystems, and > the count of both have grown quiet a lot in the last years. So it's > rather difficult to maintain a proper link order.
Files move around very rarely, is this really an issue? > Another problem is that the link order can't be modified dynamically at > boot time to include dependencies dictated by the hardware. To circumvent > this, a brute-force trial-and-error mechanism called deferred probes has > been introduced, but this approach, while beeing KISS, has its own > problems. What problems does deferred probing have? Why not just fix that if there is issues with it, as it was supposed to solve this issue without needing to annotate anything. > To solve these problems I've written patches to use a topological sort at > boot time which uses dependencies to calculate the order with which > initcalls are called. > > Why? What are the benefits (assuming correct dependencies are available)? > > - It offers a clear in-source documentation for dependencies between > initcalls. > - It is robust in regard to file or directory name changes and changes in > a Makefile. > - If enabled, the order with which drivers for interfaces are called > (e.g. network interfaces, hard disks), can be defined independent of > the link order. These might result in more stable interface names or > numbers. > - If enabled, it makes the the deferred probes obsolete, which might > result in faster boot times. > - If enabled, it is possible to call initcalls in parallel. E.g. the > shipped kernel for Fedora 21 (4.1.7-100.fc21.x86_64) contains around > 560 initcalls. These are all called in series. Also some of them use > asynchronous stuff by themself, most don't do. But that shipped kernel boots to X in less than 2 seconds, so there isn't really a speed issue here, right? > Drawbacks: > > - It requires a small amount of time to calculate the order a boot time. > But this time is most often smaller than the time saved by using > multiple cores to call initcalls or by not needing deferred probes. How much time is needed? > - Dependencies are required. For everything which can be build as a > module, looking at modules.dep might give some pointers. Looking at > the help from menuconfig also might give some pointers. But in the > end, the most preferable way would be if maintainers or other people > which have a deeper knowledge about the source and functionality > would add the dependencies. How will a "normal" driver author figure out what those dependancies are in order to be able to write them down? That's my biggest objection here, I have no idea how to add these, nor how to properly review such a submission. What about systems that have different ordering/dependancy requirements for the same drivers due to different ways the hardware is hooked up? That is not going to work well here, unless I'm missing something. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/