On Tue, 14 Jul 2020 15:56:52 +0200 Jessica Yu <j...@kernel.org> wrote:
> As Ard and Will have already explained, the major issue I'm having > with this is that we're taking module_alloc(), an allocator that was > originally specific to module loading, and turning it into a generic > interface to be used by other subsystems. You're pulling in all the > module loading semantics that vary by architecture and expecting it to > work as a generic text allocator. I'm not against the existence of a > generic text_alloc() but I would very much rather that module_alloc() > be left alone to the module loader and instead work on introducing a > *separate* generic text_alloc() interface that would work for its > intended users (kprobes, bpf, etc) and have existing users of > module_alloc() switch to that instead. Looks like the consensus is to create a separate text_alloc() that can be used when modules are not configured in for things like ftrace dynamic trampolines, and keep module_alloc() untouched. For those concerned about added unused code for architectures that don't need text_alloc(), we can always create a config called: CONFIG_ARCH_NEED_TEXT_ALLOC, and the arch can add that to its list of kconfigs if it intends to use text_alloc(). -- Steve
