From: Randy Dunlap <[email protected]>
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 <[email protected]>
Cc: Artem Bityutskiy <[email protected]>
Cc: Adrian Hunter <[email protected]>
Cc: [email protected]
---
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
On Mon, 2011-03-28 at 13:40 -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> 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 (Артём Битюцкий)
On 03/29/11 00:02, Artem Bityutskiy wrote:
> On Mon, 2011-03-28 at 13:40 -0700, Randy Dunlap wrote:
>> From: Randy Dunlap <[email protected]>
>>
>> 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 ***
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 <[email protected]>
> >>
> >> 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 (Артём Битюцкий)
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 <[email protected]>
> > >>
> > >> 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 <[email protected]>
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 <[email protected]>
Cc: Artem Bityutskiy <[email protected]>
Cc: Adrian Hunter <[email protected]>
Cc: [email protected]
---
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
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 <[email protected]>
> > > >>
> > > >> 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 (Артём Битюцкий)
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<[email protected]>
>>>>>>
>>>>>> 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.
---