* [PATCH] ubifs: fix kconfig dependency warning @ 2011-03-28 20:40 Randy Dunlap 2011-03-29 7:02 ` Artem Bityutskiy 0 siblings, 1 reply; 7+ messages in thread From: Randy Dunlap @ 2011-03-28 20:40 UTC (permalink / raw) To: lkml; +Cc: linux-mtd, Artem Bityutskiy, Adrian Hunter From: Randy Dunlap <randy.dunlap@oracle.com> Fix another kconfig dependency warning, this time in ubifs. warning: (UBIFS_FS_DEBUG && LOCKDEP && LATENCYTOP) selects KALLSYMS_ALL which has unmet direct dependencies (DEBUG_KERNEL && KALLSYMS) Without this patch, we can have: # CONFIG_KALLSYMS is not set CONFIG_KALLSYMS_ALL=y which is useless (does nothing unless KALLSYMS is enabled). However, ubifs builds successfully with or without this patch, and it builds with this line completely deleted, so what was this 'select' for? Just developer convenience? Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Artem Bityutskiy <dedekind1@gmail.com> Cc: Adrian Hunter <adrian.hunter@nokia.com> Cc: linux-mtd@lists.infradead.org --- fs/ubifs/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.38-git18.orig/fs/ubifs/Kconfig +++ linux-2.6.38-git18/fs/ubifs/Kconfig @@ -47,7 +47,7 @@ config UBIFS_FS_DEBUG bool "Enable debugging support" depends on UBIFS_FS select DEBUG_FS - select KALLSYMS_ALL + select KALLSYMS_ALL if DEBUG_KERNEL && KALLSYMS help This option enables UBIFS debugging support. It makes sure various assertions, self-checks, debugging messages and test modes are compiled ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ubifs: fix kconfig dependency warning 2011-03-28 20:40 [PATCH] ubifs: fix kconfig dependency warning Randy Dunlap @ 2011-03-29 7:02 ` Artem Bityutskiy 2011-03-29 15:01 ` Randy Dunlap 0 siblings, 1 reply; 7+ messages in thread From: Artem Bityutskiy @ 2011-03-29 7:02 UTC (permalink / raw) To: Randy Dunlap; +Cc: lkml, linux-mtd, Adrian Hunter On Mon, 2011-03-28 at 13:40 -0700, Randy Dunlap wrote: > From: Randy Dunlap <randy.dunlap@oracle.com> > > Fix another kconfig dependency warning, this time in ubifs. > > warning: (UBIFS_FS_DEBUG && LOCKDEP && LATENCYTOP) selects KALLSYMS_ALL which has unmet direct dependencies (DEBUG_KERNEL && KALLSYMS) > > Without this patch, we can have: > # CONFIG_KALLSYMS is not set > CONFIG_KALLSYMS_ALL=y > which is useless (does nothing unless KALLSYMS is enabled). > > However, ubifs builds successfully with or without this patch, > and it builds with this line completely deleted, > so what was this 'select' for? Just developer convenience? Well, here is the idea. You can compile UBIFS with debugging and without debugging. Without debugging the resulting ubifs.ko is much smaller, so some embedded people prefer it this way. If you select debugging support, then we'll compile it a lot of assertions, self-checks, test-modes, extra error messages with detailed dumps. And we want to see stackdumps when errors or problems happen, this is why we select KALLSYMS_ALL. So I guess instead we should do: select KALLSYMS select KALLSYMS_ALL ? -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ubifs: fix kconfig dependency warning 2011-03-29 7:02 ` Artem Bityutskiy @ 2011-03-29 15:01 ` Randy Dunlap 2011-03-29 15:04 ` Artem Bityutskiy 0 siblings, 1 reply; 7+ messages in thread From: Randy Dunlap @ 2011-03-29 15:01 UTC (permalink / raw) To: dedekind1; +Cc: lkml, linux-mtd, Adrian Hunter On 03/29/11 00:02, Artem Bityutskiy wrote: > On Mon, 2011-03-28 at 13:40 -0700, Randy Dunlap wrote: >> From: Randy Dunlap <randy.dunlap@oracle.com> >> >> Fix another kconfig dependency warning, this time in ubifs. >> >> warning: (UBIFS_FS_DEBUG && LOCKDEP && LATENCYTOP) selects KALLSYMS_ALL which has unmet direct dependencies (DEBUG_KERNEL && KALLSYMS) >> >> Without this patch, we can have: >> # CONFIG_KALLSYMS is not set >> CONFIG_KALLSYMS_ALL=y >> which is useless (does nothing unless KALLSYMS is enabled). >> >> However, ubifs builds successfully with or without this patch, >> and it builds with this line completely deleted, >> so what was this 'select' for? Just developer convenience? > > Well, here is the idea. You can compile UBIFS with debugging and without > debugging. Without debugging the resulting ubifs.ko is much smaller, so > some embedded people prefer it this way. > > If you select debugging support, then we'll compile it a lot of > assertions, self-checks, test-modes, extra error messages with detailed > dumps. And we want to see stackdumps when errors or problems happen, > this is why we select KALLSYMS_ALL. > > So I guess instead we should do: > > select KALLSYMS > select KALLSYMS_ALL Yes, that should do it. Thanks for the explanation. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ubifs: fix kconfig dependency warning 2011-03-29 15:01 ` Randy Dunlap @ 2011-03-29 15:04 ` Artem Bityutskiy 2011-03-29 15:48 ` [PATCH v2] " Randy Dunlap 0 siblings, 1 reply; 7+ messages in thread From: Artem Bityutskiy @ 2011-03-29 15:04 UTC (permalink / raw) To: Randy Dunlap; +Cc: lkml, linux-mtd, Adrian Hunter On Tue, 2011-03-29 at 08:01 -0700, Randy Dunlap wrote: > On 03/29/11 00:02, Artem Bityutskiy wrote: > > On Mon, 2011-03-28 at 13:40 -0700, Randy Dunlap wrote: > >> From: Randy Dunlap <randy.dunlap@oracle.com> > >> > >> Fix another kconfig dependency warning, this time in ubifs. > >> > >> warning: (UBIFS_FS_DEBUG && LOCKDEP && LATENCYTOP) selects KALLSYMS_ALL which has unmet direct dependencies (DEBUG_KERNEL && KALLSYMS) > >> > >> Without this patch, we can have: > >> # CONFIG_KALLSYMS is not set > >> CONFIG_KALLSYMS_ALL=y > >> which is useless (does nothing unless KALLSYMS is enabled). > >> > >> However, ubifs builds successfully with or without this patch, > >> and it builds with this line completely deleted, > >> so what was this 'select' for? Just developer convenience? > > > > Well, here is the idea. You can compile UBIFS with debugging and without > > debugging. Without debugging the resulting ubifs.ko is much smaller, so > > some embedded people prefer it this way. > > > > If you select debugging support, then we'll compile it a lot of > > assertions, self-checks, test-modes, extra error messages with detailed > > dumps. And we want to see stackdumps when errors or problems happen, > > this is why we select KALLSYMS_ALL. > > > > So I guess instead we should do: > > > > select KALLSYMS > > select KALLSYMS_ALL > > Yes, that should do it. Thanks for the explanation. Will you submit a patch? Alternatively, I can make it myself. What is your preference? And I'll merge it upstream this cycle (before 2.6.39) then. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v2] ubifs: fix kconfig dependency warning 2011-03-29 15:04 ` Artem Bityutskiy @ 2011-03-29 15:48 ` Randy Dunlap 2011-03-30 8:12 ` Artem Bityutskiy 0 siblings, 1 reply; 7+ messages in thread From: Randy Dunlap @ 2011-03-29 15:48 UTC (permalink / raw) To: dedekind1; +Cc: lkml, linux-mtd, Adrian Hunter On Tue, 29 Mar 2011 18:04:15 +0300 Artem Bityutskiy wrote: > On Tue, 2011-03-29 at 08:01 -0700, Randy Dunlap wrote: > > On 03/29/11 00:02, Artem Bityutskiy wrote: > > > On Mon, 2011-03-28 at 13:40 -0700, Randy Dunlap wrote: > > >> From: Randy Dunlap <randy.dunlap@oracle.com> > > >> > > >> Fix another kconfig dependency warning, this time in ubifs. > > >> > > >> warning: (UBIFS_FS_DEBUG && LOCKDEP && LATENCYTOP) selects KALLSYMS_ALL which has unmet direct dependencies (DEBUG_KERNEL && KALLSYMS) > > >> > > >> Without this patch, we can have: > > >> # CONFIG_KALLSYMS is not set > > >> CONFIG_KALLSYMS_ALL=y > > >> which is useless (does nothing unless KALLSYMS is enabled). > > >> > > >> However, ubifs builds successfully with or without this patch, > > >> and it builds with this line completely deleted, > > >> so what was this 'select' for? Just developer convenience? > > > > > > Well, here is the idea. You can compile UBIFS with debugging and without > > > debugging. Without debugging the resulting ubifs.ko is much smaller, so > > > some embedded people prefer it this way. > > > > > > If you select debugging support, then we'll compile it a lot of > > > assertions, self-checks, test-modes, extra error messages with detailed > > > dumps. And we want to see stackdumps when errors or problems happen, > > > this is why we select KALLSYMS_ALL. > > > > > > So I guess instead we should do: > > > > > > select KALLSYMS > > > select KALLSYMS_ALL > > > > Yes, that should do it. Thanks for the explanation. > > Will you submit a patch? Alternatively, I can make it myself. What is > your preference? Here's an updated patch. But since KALLSYMS_ALL depends on DEBUG_KERNEL, the lines above aren't quite sufficient and I don't care to select DEBUG_KERNEL. --- From: Randy Dunlap <randy.dunlap@oracle.com> Fix kconfig dependency warning in ubifs: warning: (UBIFS_FS_DEBUG && LOCKDEP && LATENCYTOP) selects KALLSYMS_ALL which has unmet direct dependencies (DEBUG_KERNEL && KALLSYMS) Without this patch, we can have: # CONFIG_KALLSYMS is not set CONFIG_KALLSYMS_ALL=y which is useless (does nothing unless KALLSYMS is enabled). Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Artem Bityutskiy <dedekind1@gmail.com> Cc: Adrian Hunter <adrian.hunter@nokia.com> Cc: linux-mtd@lists.infradead.org --- fs/ubifs/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- linux-next-20110328.orig/fs/ubifs/Kconfig +++ linux-next-20110328/fs/ubifs/Kconfig @@ -47,7 +47,8 @@ config UBIFS_FS_DEBUG bool "Enable debugging support" depends on UBIFS_FS select DEBUG_FS - select KALLSYMS_ALL + select KALLSYMS + select KALLSYMS_ALL if DEBUG_KERNEL help This option enables UBIFS debugging support. It makes sure various assertions, self-checks, debugging messages and test modes are compiled ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] ubifs: fix kconfig dependency warning 2011-03-29 15:48 ` [PATCH v2] " Randy Dunlap @ 2011-03-30 8:12 ` Artem Bityutskiy 2011-03-30 17:34 ` Randy Dunlap 0 siblings, 1 reply; 7+ messages in thread From: Artem Bityutskiy @ 2011-03-30 8:12 UTC (permalink / raw) To: Randy Dunlap; +Cc: lkml, linux-mtd, Adrian Hunter On Tue, 2011-03-29 at 08:48 -0700, Randy Dunlap wrote: > On Tue, 29 Mar 2011 18:04:15 +0300 Artem Bityutskiy wrote: > > > On Tue, 2011-03-29 at 08:01 -0700, Randy Dunlap wrote: > > > On 03/29/11 00:02, Artem Bityutskiy wrote: > > > > On Mon, 2011-03-28 at 13:40 -0700, Randy Dunlap wrote: > > > >> From: Randy Dunlap <randy.dunlap@oracle.com> > > > >> > > > >> Fix another kconfig dependency warning, this time in ubifs. > > > >> > > > >> warning: (UBIFS_FS_DEBUG && LOCKDEP && LATENCYTOP) selects KALLSYMS_ALL which has unmet direct dependencies (DEBUG_KERNEL && KALLSYMS) > > > >> > > > >> Without this patch, we can have: > > > >> # CONFIG_KALLSYMS is not set > > > >> CONFIG_KALLSYMS_ALL=y > > > >> which is useless (does nothing unless KALLSYMS is enabled). > > > >> > > > >> However, ubifs builds successfully with or without this patch, > > > >> and it builds with this line completely deleted, > > > >> so what was this 'select' for? Just developer convenience? > > > > > > > > Well, here is the idea. You can compile UBIFS with debugging and without > > > > debugging. Without debugging the resulting ubifs.ko is much smaller, so > > > > some embedded people prefer it this way. > > > > > > > > If you select debugging support, then we'll compile it a lot of > > > > assertions, self-checks, test-modes, extra error messages with detailed > > > > dumps. And we want to see stackdumps when errors or problems happen, > > > > this is why we select KALLSYMS_ALL. > > > > > > > > So I guess instead we should do: > > > > > > > > select KALLSYMS > > > > select KALLSYMS_ALL > > > > > > Yes, that should do it. Thanks for the explanation. > > > > Will you submit a patch? Alternatively, I can make it myself. What is > > your preference? > > Here's an updated patch. But since KALLSYMS_ALL depends on DEBUG_KERNEL, > the lines above aren't quite sufficient and I don't care to select > DEBUG_KERNEL. What is the real difference between KALLSYMS_ALL and KALLSYMS? It looks like for stack dumps KALLSYMS is enough. The Kconfig help text is not very helpful. And when I look at the help text of CONFIG_KALLSYMS_EXTRA_PASS I get feeling that this area needs some clean-up work. Anyway, any idea why we wouldn't just kill KALLSYMS_ALL by merging it with KALLSYMS? -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] ubifs: fix kconfig dependency warning 2011-03-30 8:12 ` Artem Bityutskiy @ 2011-03-30 17:34 ` Randy Dunlap 0 siblings, 0 replies; 7+ messages in thread From: Randy Dunlap @ 2011-03-30 17:34 UTC (permalink / raw) To: dedekind1; +Cc: lkml, linux-mtd, Adrian Hunter On 3/30/2011 1:12 AM, Artem Bityutskiy wrote: > On Tue, 2011-03-29 at 08:48 -0700, Randy Dunlap wrote: >> On Tue, 29 Mar 2011 18:04:15 +0300 Artem Bityutskiy wrote: >> >>> On Tue, 2011-03-29 at 08:01 -0700, Randy Dunlap wrote: >>>> On 03/29/11 00:02, Artem Bityutskiy wrote: >>>>> On Mon, 2011-03-28 at 13:40 -0700, Randy Dunlap wrote: >>>>>> From: Randy Dunlap<randy.dunlap@oracle.com> >>>>>> >>>>>> Fix another kconfig dependency warning, this time in ubifs. >>>>>> >>>>>> warning: (UBIFS_FS_DEBUG&& LOCKDEP&& LATENCYTOP) selects KALLSYMS_ALL which has unmet direct dependencies (DEBUG_KERNEL&& KALLSYMS) >>>>>> >>>>>> Without this patch, we can have: >>>>>> # CONFIG_KALLSYMS is not set >>>>>> CONFIG_KALLSYMS_ALL=y >>>>>> which is useless (does nothing unless KALLSYMS is enabled). >>>>>> >>>>>> However, ubifs builds successfully with or without this patch, >>>>>> and it builds with this line completely deleted, >>>>>> so what was this 'select' for? Just developer convenience? >>>>> >>>>> Well, here is the idea. You can compile UBIFS with debugging and without >>>>> debugging. Without debugging the resulting ubifs.ko is much smaller, so >>>>> some embedded people prefer it this way. >>>>> >>>>> If you select debugging support, then we'll compile it a lot of >>>>> assertions, self-checks, test-modes, extra error messages with detailed >>>>> dumps. And we want to see stackdumps when errors or problems happen, >>>>> this is why we select KALLSYMS_ALL. >>>>> >>>>> So I guess instead we should do: >>>>> >>>>> select KALLSYMS >>>>> select KALLSYMS_ALL >>>> >>>> Yes, that should do it. Thanks for the explanation. >>> >>> Will you submit a patch? Alternatively, I can make it myself. What is >>> your preference? >> >> Here's an updated patch. But since KALLSYMS_ALL depends on DEBUG_KERNEL, >> the lines above aren't quite sufficient and I don't care to select >> DEBUG_KERNEL. > > What is the real difference between KALLSYMS_ALL and KALLSYMS? It looks > like for stack dumps KALLSYMS is enough. The Kconfig help text is not > very helpful. And when I look at the help text of > CONFIG_KALLSYMS_EXTRA_PASS I get feeling that this area needs some > clean-up work. Yes, KALLSYMS is enough for most of us. You can see what KALLSYMS_ALL does by looking at scripts/kallsyms.c, the --all-symbols option: > /* if --all-symbols is not specified, then symbols outside the text > * and inittext sections are discarded */ > Anyway, any idea why we wouldn't just kill KALLSYMS_ALL by merging it > with KALLSYMS? KALLSYMS_ALL probably generates noise for most use cases. --- ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-03-30 17:34 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-03-28 20:40 [PATCH] ubifs: fix kconfig dependency warning Randy Dunlap 2011-03-29 7:02 ` Artem Bityutskiy 2011-03-29 15:01 ` Randy Dunlap 2011-03-29 15:04 ` Artem Bityutskiy 2011-03-29 15:48 ` [PATCH v2] " Randy Dunlap 2011-03-30 8:12 ` Artem Bityutskiy 2011-03-30 17:34 ` Randy Dunlap
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).