On Mon, 2009-05-11 at 09:22 +0100, Alan Jenkins wrote: > Andreas Robinson wrote: > > > > That the strings are malloc'd elsewhere should not be a problem if the > > caller is aware that the strings are in the ELF-file and that they > > remain available until release_file() is called. Depmod can't release > > any of the modules until it is finished. > > > > Withdrawn. > > Sorry, I'm too quick to jump to conclusions :-(. I thought the symbol > names were being copied onto the heap, but they're clearly not. I'm not > worried about string constants per se. I was mistakenly concerned that > one data structure was being used to return strings with very different > lifecycle rules. > > It's an important issue, so you might make this more explicit. One way > would be to add an inline strtbl_free() (which collapses to free()). > But you are also welcome to dismiss me as a hopeless reader and leave it > as is:-). No you are not a hopeless reader. :) And I appreciate the feedback. I do need to explain myself better. I never come up with a good solution on the first attempt and usually need a few hours (or days) to figure out the little details that make a particular design choice "obvious", even though it's anything but. > > Oh, and could you please send me add --valgrind patch please? > > > > I wasn't subscribed to this list when you posted it and the archive has > > mangled it somehow. (Or PEBKAC, more likely.) > > > > Oh, sorry! I assumed it had already been applied. I'll resend it and > see if it wakes Jon up. It might have been my fault for forgetting to > put [PATCH] in the subject line. > > Btw, I'm being serious when I talk about it being slow. "valgrind > ./depmod" should be enough to reproduce this one issue, so do that first > :-). Ok, I will. :) A plain "time depmod" runs about 25 times faster than "time valgrind depmod". The full test suite would then be about 10 - 12 minutes on my machine ... Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
