On Sun, Oct 6, 2019 at 10:24 PM Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > On Mon, 7 Oct 2019 at 06:44, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > > > > Actually, this can be addressed by retaining the module dependencies > > > as before, but permitting the arch module to be omitted at load time. > > > > I think that, to avoid surprises, you should refuse to load the arch module if the generic module is loaded, too. > > > > Most arch code depends on CPU features that may not be available given > the context, either because they are SIMD or because they are optional > CPU instructions. So we need both modules at the same time anyway, so > that we can fall back to the generic code at runtime. > > So what I'd like is to have the generic module provide the library > interface, but rely on arch modules that are optional. > > We already have 95% of what we need with weak references. We have the > ability to test for presence of the arch code at runtime, and we even > have code patching for all architectures (through static relocations). > > However, one could argue that this is more a [space] optimization than > anything else, so I am willing to park this discussion until support > for static calls has been merged, and proceed with something simpler. I'd suggest tabling it until static calls are merged. PeterZ just sent a new patchbomb for it anyway. What I'm trying to get at here and apparently saying badly is that I want to avoid a situation where lsmod shows the arch module loaded but the arch code isn't actually executing. Regardless of how everything gets wired up (static calls, weak refs, etc), the system's behavior should match the system's configuration, which means that we should not allow any improper order of loading things so that everything *appears* to be loaded but does not actually function. Saying "modprobe will do the right thing and let's not worry about silly admins using insmod directly" is not a good solution.
