Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH 2/2] module: fix bne2 "gave up waiting for init of module libcrc32c" | Date | Fri, 4 Jun 2010 10:32:03 +0930 |
| |
On Fri, 4 Jun 2010 01:54:19 am Linus Torvalds wrote: > > On Thu, 3 Jun 2010, Rusty Russell wrote: > > > > However, you're right that it has potential. I'll rename module_info to > > load_info if you don't mind tho: contains more semantic punch IMHO. > > Umm. One problem is that you will almost certainly eventually want to > expose that to the architecture "fixup" routines (ie things like > module_frob_arch_sections(), arch_mod_section_prepend()), and at that > point "load_info" is a horribly bad structure name, since it would show > up in <linux/module.h> and thus be exported all over. > > At least call it "struct module_load_info". But yes, I do agree that the > "load" part is important.
Looking at the arch code, it has the advantage that it's self-contained. They've been pleasantly undemanding from the core over the years; I think archs doing tricky things with elf prefer to parse the object themselves anyway. And I'm not sure they want to revisit it, either.
So I don't think we'd win much from changing them. I'm wrong later, I'll prepend "module_" to the struct name as an internal change then hit them all.
> I looked at that particularly when doing that whole > > mod = setup_module_info(&info); > if (IS_ERR(mod)) { > err = PTR_ERR(mod); > goto free_hdr; > } > > thing, because that made "mod" have _three_ totally different values > (error, before, after) when jumping out to the failure paths.
Yep, it now is back to sanity. Let's see if today's linux-next is happy.
If so, do you want just the fixes or the whole refactoring too, while it's nice and fresh?
Thanks! Rusty.
| |