AFAICT, that would hurt some archs. Of course, you could say "modules
are meant to be slow" but I don't think that would win you any
friends 8)
I haven't thought about it hard: for some archs it might make perfect
sense, but I'm not sure what more than dropping the hdr->e_type check
would be required.
> This does reduce the freedom to allocate the init sections completely
> separately from the core sections, but that seems a small price to pay
> for the extreme reduction in complexity for the in-kernel loader.
Note: "extreme reduction" is probably overstating. There are only
about 300 lines of linker code in the kernel (x86). The rest of the
1400 lines is refcount manipulation, usage detection, symbol lookup,
system call code, /proc stuff.
But I think you could do this for any arch now by allocating the whole
module in the core alloc, and returning a pointer the the start of the
init section for the second "alloc". The "free" of the init section
then only frees those trailing pages.
I have no problem with the idea, if we can keep the per-arch
flexibility.
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/