On Wed 2015-12-16 00:40:48, Jessica Yu wrote: > Turns out the string parsing stuff, even with the help of lib/string.c, > doesn't > look very pretty. As I'm working on v3, I'm starting to think having > klp_write_object_relocations() loop simply through all the elf sections might > not be a good idea. Let me explain. > > I don't like the amount of string manipulation code that would potentially > come > with this change. Even with a string as simple as ".klp.rela.objname", we'll > end up with a bunch of kstrdup's/kmalloc's and kfree's (unless we modify and > chop the section name string in place, which I don't think we should do) that > are going to be required at every iteration of the loop, all just to be able > to > call strcmp() and see if we're dealing with a klp rela section that belongs to > the object in question. This also leads to more complicated error handling.
I do not think that we need to allocate and free buffers every time we compare a substring. One possibility is to find the position of the substring using strchr(). Then you could compare it using strncmp() and pass there the pointer where the substring begins. Alternatively we could use a static buffer or allocate a big enough one at the beginning. IMHO, we could assume that function name must fit into 80 characters, otherwise, that code would be unmanageable (won't deserve patching). If we use a buffer size 256 bytes, we should be definitely on the safe side. Just 2 my cents, Petr -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
