On Sun Sep 6, 2026 at 10:56 AM BST, Arnd Bergmann wrote: > On Sun, Sep 6, 2026, at 02:28, Andrew Morton wrote: >> On Fri, 4 Sep 2026 10:59:38 -0400 Aaron Tomlin <[email protected]> wrote: >>> >>> In summary, this patch brings parity between modular and built-in drivers, >>> removes a pain point in boot-time disaster recovery, and provides users >>> with a predictable, consistent interface. >> >> Really helpful, thanks. Please add this to the [0/N] and maintain it. >> >> I don't really know who are the potential audience for this change, nor >> how to attract their attention. Greg might have some insights but he >> wasn't cc'ed. >> >> Let's leave it a week to see if there's feedback then resend with these >> adjustments? > > FWIW, I previously asked the same question on this series > and still don't find the explanation lacking. Obviously, > consistency is good, but the added complexity doesn't feel > worth it here, given that this still has most of the same > problems as the existing "initcall_blacklist=" option [1].
Yeah, I like the better consistency, which is why I propose unifying handling for both built-in modules and loadable ones in https://lore.kernel.org/all/[email protected]/. IMO if we can unify them, then we get something that is both consistent and *less* complexity. The current solution makes thing more complex with only apparent consistency (i.e. user observe the consistency from kernel parameter, but the internal handling are two separate mechanisms), which should require a very strong reason to pursue. Best, Gary > > I think patch 2/2 would be fine on its own, but for 1/2 > I have yet to see a single example of a real-world problem > that could have been solved by this but not using > initcall_blacklist. In distro kernels, almost everything > is already a loadable module, while users with custom > kernels could easily turn off the drivers they don't want > or disable the initcall by name. > > Arnd > > [1] > https://lore.kernel.org/all/[email protected]/
