[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a781481a0705191632l5d57a044r46317321ac463f88@mail.gmail.com>
Date: Sun, 20 May 2007 05:02:55 +0530
From: "Satyam Sharma" <satyam.sharma@...il.com>
To: "Adrian Bunk" <bunk@...sta.de>
Cc: "Andrew Morton" <akpm@...ux-foundation.org>,
"Sam Ravnborg" <sam@...nborg.org>,
LKML <linux-kernel@...r.kernel.org>,
"Roman Zippel" <zippel@...ux-m68k.org>
Subject: Re: RFC: kconfig select warnings bogus?
On 5/20/07, Adrian Bunk <bunk@...sta.de> wrote:
> On Sun, May 20, 2007 at 04:51:44AM +0530, Satyam Sharma wrote:
> > On 5/20/07, Satyam Sharma <satyam.sharma@...il.com> wrote:
> >> On 5/20/07, Adrian Bunk <bunk@...sta.de> wrote:
> >> > On Sat, May 19, 2007 at 11:09:44AM -0700, Andrew Morton wrote:
> >> > > On Sat, 19 May 2007 17:15:23 +0200 Sam Ravnborg <sam@...nborg.org>
> >> wrote:
> >> > >
> >> > > > We see a lot of these lately:
> >> > > > GEN /home/bor/build/linux-2.6.22/Makefile
> >> > > > scripts/kconfig/conf -s arch/i386/Kconfig
> >> > > > drivers/macintosh/Kconfig:116:warning: 'select' used by config
> >> symbol 'PMAC_APM_EMU' refers to undefined symbol
> >> 'SYS_SUPPORTS_APM_EMULATION'
> >> > > > drivers/net/Kconfig:2283:warning: 'select' used by config symbol
> >> 'UCC_GETH' refers to undefined symbol 'UCC_FAST'
> >> > > > drivers/input/keyboard/Kconfig:170:warning: 'select' used by config
> >> symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
> >> > > > drivers/input/mouse/Kconfig:182:warning: 'select' used by config
> >> symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
> >> > > >
> >> > > >
> >> > > > Do this warning really add any value or should we just ignore them
> >> like this?
> >> > > >
> >> > >
> >> > > They always indicate Kconfig bugs, don't they? If so, we should keep
> >> the
> >> > > warning.
> >> > >...
> >> >
> >> > No, they aren't always.
> >> >
> >> > Look for example at the last one in drivers/input/mouse/Kconfig:
> >> >
> >> > config MOUSE_ATARI
> >> > tristate "Atari mouse"
> >> > depends on ATARI
> >> > select ATARI_KBD_CORE
> >> >
> >> > This is perfectly correct (the select'ed symbol is only unavailable when
> >> > the dependency can't be fulfilled), and all things to "fix" the warning
> >> > will make it worse.
> >>
> >> Not sure what you mean here. The select'ed symbol here is unavailable
> >> because not all arch's define it. However, the symbol that selects it is
> >> in drivers/input/... and hence run for all arch's. That's the simple issue
> >> here that is resolved by this fix.
> >
> > And by the way, this is precisely the case for _all_ the select issues in
> > this
> > patch (the four that were raised by Sam) -- i.e. only one arch defining a
> > config option that is selected by stuff in drivers/... which is common for
> > all archs, and hence the warnings on other archs.
> >
> > I don't see any problem at all that is introduced / "made worse" by the
> > patch, it just rectifies the problem to get rid of the warnings.
>
> There's no doubt that it gets rid of the warnings.
Ah, ok, so you're saying that these warnings would not lead to build
failures in any case, so we might as well not print the warnings at all?
I can't confirm that, have never tried to build these drivers here (don't
have m68k / powerpc boxen), so perhaps you're right.
> But the warnings don't point to problems and the "fixes" for the
> warnings make the Kconfig's worse.
>
> If fixing warnings makes something not better but worse, it's always
> worth a thought whether to disable the warning.
There is nothing that is "made worse" by the "select -> default .. if .."
kind of conversion here.
In any case, the problem with Sam's patch is that it gets rid of
warnings for all cases where someone is trying to "select" a config
option that does not exist at all (and perhaps some of those cases
_could_ lead to build breakages).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists