On Fri, 24 Oct 2014, Geert Uytterhoeven wrote: > Several patches are linked from > http://elinux.org/Deferred_Initcalls > > Latest version is > http://elinux.org/images/5/51/0001-Port-deferred-initcalls-to-3.10.patch In the hope of providing some constructive and concrete feedback to this thread, here's what I have to say about the patch linked above ( I looked only at the latest version): - Commented out code is not acceptable for mainline. But everyone knows that already. - Returning a null byte through the /proc file is dubious. - The /proc interface is probably not the best. I'd go with an entry in /sys/kernel instead. - If the deferred_initcall section is empty, this could return 1 upfront and do the free_initmem() earlier as it used to. - It was mentioned somewhere that the config system could use a 4th state in addition to n, m and y. That would be required before this goes upstream simply to express all the dependencies between modules. Right now if a core module is configured with m, then all the submodules that depend on it inherit the modular-only restriction. The same would need to be enforced for deferred initcalls. - Currently all deferred initcalls are lumped together in a single section with no regards to the original initcall level. This is likely to cause trouble if two initcalls are called in a different order than intended. Nothing prevents that from happening right now. This patch is still not generic enough for mainline inclusion IMHO. It currently falls in the "you better know what you're doing" category and that is possibly good enough for its actual users. Trying to make this more generic is going to require some more work. And this would have to come with serious arguments explaining why simply using modules in the first place is not acceptable. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
