module: fix bne2 "gave up waiting for init of module libcrc32c"
in [Kernel]
|
Prev: [regression] Please add bug 15788 and 15969, usb sound / radeon kms broken after snapshot cycle
Next: [PATCH] staging: comedi - correct parameter gainlkup for DAQCard-6024E in driver ni_mio_cs.c
From: Linus Torvalds on 3 Jun 2010 22:10 On Fri, 4 Jun 2010, Rusty Russell wrote: > > > > 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. Ok. So if we don't expect to ever pass the full load_info struct down to the arch code, and we can keep it entirely internal to module.c, then "struct load_info" is fine by me. > If so, do you want just the fixes or the whole refactoring too, while > it's nice and fresh? Gaah. "Just the fixes" is definitely the prudent thing to do. At the same time, I've now so deeply bought into the whole cleanup thing too, that I want to argue that the cleanup might make it easier to handle any locking problems if we find them. But I suspect that is just myself trying to fool/argue my smarter half into taking it all. So you can probably push me either way. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 4 Jun 2010 19:00
On Fri, 4 Jun 2010, Rusty Russell wrote: > On Fri, 4 Jun 2010 11:25:00 am Linus Torvalds wrote: > > But I suspect that is just myself trying to fool/argue my smarter half > > into taking it all. > > Similar motivation for even asking. > > They can stew in linux-next for another cycle: just found a trivial > !SMP compile issue, and with all the other config options in there > it could use some baking... Yeah, considering the ia64 report, I can't lie to myself and say that the cleanups are going to be totally safe. Can you send me a pointer to the safe/bugfix part, and I'll pull it for -rc2? I'd like to do that Saturday. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |