On Thu, Sep 4, 2008 at 6:35 AM, Alexey Zaytsev <alexey.zaytsev@xxxxxxxxx> wrote: >> Ok, let me try to explain how the stuff works. Please note that in > > Ugh, my pretty code listings got corrupted by the bloody gmail. > Here is a better version: http://zaytsev.su/explanation.txt Thanks for your detail explain. It just confirm my reading of your code. I stand by my original feedback: - Using C source code as the output format is bad and unnecessary. It depend on gcc to process the intermediate C source file. - Using dlopen to load the module does not have the fine grain control of the which symbol need to resolve and which is doesn't. The linked sparse object code for the whole linux kernel will be huge. Dynamic loading of 300M bytes of .so file is not fun. - I can see you link all the define symbol together that way. In order to do inter-function check effectively, we need the have the reverse mapping as well. It need to perform task like this: "Get me a list of the function who has reference to spin_lock()". If I am writing a spin_lock checker. I can look at who used spin_lock and only load those functions as needed. It is much better than scanning every single one of the kernel function to search for the spin_lock function call. - The extra 4 bytes per structure storage on disk can be eliminated. I agree you need some meta data to track the object before you dump them to the file. But they don't need to be on the disk object at all. If you group same type of object together as an array. The index of the object is implicit as the array index. If the C struct is fixed size. It is trivial to locate the object. If the C struct is variable size, currently on sparse each object knows what size it is. You do need any index array to look it up. But this array can be build on object loading time. They don't have to be on the disk either. Then you can get ride of the wrapper structure on the disk file format all together. The writer patch I send out use those tricks already. You are welcome to poke around it. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
