From: Artem Bityutskiy <dedekind1@gmail.com>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: MTD list <linux-mtd@lists.infradead.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: [PATCH 0/2] do not select KALLSYMS_ALL
Date: Wed, 30 Mar 2011 11:40:14 +0300 [thread overview]
Message-ID: <1301474416-8202-1-git-send-email-dedekind1@gmail.com> (raw)
UBI and UBIFS have an option to compile-in debugging support. When we enable
debugging, compile-in various assertions, self-check functions and test modes.
We also compile in additional verbose error messages, flash dumps and stack
dumps.
When we have debugging support enabled, we want to have nice stackdumps, so
we selected KALLSYMS_ALL. But this causes various problems like unmet direct
dependencies, reported by Randy:
warning: (UBIFS_FS_DEBUG && LOCKDEP && LATENCYTOP) selects KALLSYMS_ALL which
has unmet direct dependencies (DEBUG_KERNEL && KALLSYMS)
I quickly looked at KALLSYMS_ALL and it is not immediately clear what exactly
is the difference between KALLSYMS and KALLSYMS_ALL. And there is this
CONFIG_KALLSYMS_EXTRA_PASS symbol, which is declared "temporary workaround"
in the Kconfig help. This shows that this stuff is messy.
I personally think KALLSYMS_ALL should be just merged with KALLSYMS and
disappear - we should have only one option. CONFIG_KALLSYMS_EXTRA_PASS should
die as well.
But I don't want to delve into that, I choose to just forget about KALLSYMS_ALL
and select KALLSYMS in UBI/UBIFS which seems to be enough for us.
Artem.
next reply other threads:[~2011-03-30 8:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-30 8:40 Artem Bityutskiy [this message]
2011-03-30 8:40 ` [PATCH 1/2] UBIFS: do not select KALLSYMS_ALL Artem Bityutskiy
2011-03-30 22:41 ` Randy Dunlap
2011-03-31 6:29 ` Artem Bityutskiy
2011-03-30 8:40 ` [PATCH 2/2] UBI: " Artem Bityutskiy
2011-03-30 22:41 ` Randy Dunlap
2011-03-31 14:18 ` [PATCH 0/2] " Paulo Marques
2011-04-01 14:40 ` Artem Bityutskiy
2011-04-01 14:56 ` Artem Bityutskiy
2011-04-01 15:01 ` Artem Bityutskiy
2011-04-01 15:11 ` Ricard Wanderlof
2011-04-01 15:34 ` Paulo Marques
2011-04-01 15:42 ` Artem Bityutskiy
2011-04-01 15:54 ` Paulo Marques
2011-04-04 7:12 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1301474416-8202-1-git-send-email-dedekind1@gmail.com \
--to=dedekind1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=randy.dunlap@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox