[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0708131542190.15546@localhost.localdomain>
Date: Mon, 13 Aug 2007 15:44:16 -0400 (EDT)
From: "Robert P. J. Day" <rpjday@...dspring.com>
To: Randy Dunlap <randy.dunlap@...cle.com>
cc: Adrian Bunk <bunk@...nel.org>, lkml <linux-kernel@...r.kernel.org>,
akpm <akpm@...ux-foundation.org>, sam@...nborg.org,
zippel@...ux-m68k.org, vincent.legoll@...il.com
Subject: Re: [PATCH] kconfig: update kconfig-language text
On Mon, 13 Aug 2007, Randy Dunlap wrote:
> Robert P. J. Day wrote:
> > and, as i've suggested before, it would also be cleaner to
> > remove the redundant "requires" and almost redundant "depends" from
> > Kconfig files, and standardize exclusively on "depends on".
> >
> > at the moment, there are only five Kconfig files that use the far less
> > common "depends" directive:
> >
> > ./drivers/telephony/Kconfig: depends ISA || PCI
> > ./drivers/leds/Kconfig: depends LEDS_CLASS && ARCH_H1940
> > ./drivers/input/misc/Kconfig: depends EXPERIMENTAL
> > ./arch/blackfin/Kconfig: depends BFIN_DMA_5XX
> > ./arch/powerpc/platforms/Kconfig: depends PPC_IBM_CELL_BLADE
> >
> > adjust those and there's no reason to hang on to "depends" any longer.
> >
> > rday
>
> but what problem are these? what is solved by these changes?
why support a directive that is almost entirely unused? sure, it's
not hurting anything, but it also has no value. what's the point in
continuing to support obvious redundancy in the Kconfig files and the
parser?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
-
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