Messages in this thread | | | Subject | Re: [PATCH 0/2] do not select KALLSYMS_ALL | From | Artem Bityutskiy <> | Date | Fri, 01 Apr 2011 18:42:29 +0300 |
| |
On Fri, 2011-04-01 at 16:34 +0100, Paulo Marques wrote: > Artem Bityutskiy wrote: > > On Fri, 2011-04-01 at 17:56 +0300, Artem Bityutskiy wrote: > >> Well, ok, I've measured how much is this "a lot". On an embedded arm > >> platform this makes the kernel only 1.5% larger. > > > > But in absolute numbers this is 70KiB in my case, which is indeed > > considerable amount. So, I agree that it makes sense to keep this as a > > separate option. > > Yes, and this depends a lot on the kernel configuration options you've > selected (and that 1.5% of the kernel size, might be 50%~100% of the > kallsyms table). > > IIRC, I had configurations where the KALLSYMS_ALL option was increasing > the kallsyms table from something like 150kB to above 500kB (before > compression). This was a long time ago though and I can't say exactly > what was the configuration that made this happen.
Yes, thanks, I agree that having 2 separate options is OK.
> As for the CONFIG_KALLSYMS_EXTRA_PASS, I think the original idea (it was > not mine) was that it should be off by default and then the user would > need to turn it on when something went wrong.
Yes, but my point is that this feature is about the build and it does not affect run-time, so it should not be in Kconfig.
> With an automatic makefile mechanism, the problem would go unnoticed and > it just wouldn't be fixed, increasing the kernel compile time for > everyone who hits the same troublesome configuration.
Yes, the build system may print a message:
Your symbols table is screwed, this is a bug, report about it. As a temporary workaround use "make KALLSYMS_EXTRA_PASS=1"
Or something like that.
-- Best Regards, Artem Bityutskiy (Артём Битюцкий)
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |