- 08 9月, 2005 1 次提交
-
-
由 Paulo Marques 提交于
This patch changes the way the compression algorithm works. The base algorithm is similiar to the previous but we force the compressed token size to 2. Having a fixed size compressed token allows for a lot of optimizations, and that in turn allows this code to run over *all* the symbols faster than it did before over just a subset. Having it work over all the symbols will make it behave better when symbols change positions between passes, and the "inconsistent kallsyms" messages should become less frequent. In my tests the compression ratio was degraded by about 0.5%, but the results will depend greatly on the number of symbols to compress. Signed-off-by: NPaulo Marques <pmarques@grupopie.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 28 7月, 2005 1 次提交
-
-
由 J.A. Magallon 提交于
This time I did not break anything... and they shut up gcc4 ;) Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
-
- 06 5月, 2005 1 次提交
-
-
由 David Woodhouse 提交于
The PPC32 kernel puts platform-specific functions into separate sections so that unneeded parts of it can be freed when we've booted and actually worked out what we're running on today. This makes kallsyms ignore those functions, because they're not between _[se]text or _[se]inittext. Rather than teaching kallsyms about the various pmac/chrp/etc sections, this patch adds '_[se]extratext' markers for kallsyms. Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 01 5月, 2005 1 次提交
-
-
由 Yoshinori Sato 提交于
kallsyms does not consider SYMBOL_PREFIX of C. Consequently it does not work on architectures using that prefix character (h8300, v850). Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-