[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Zoltan Devai]

Commit 592913ecb87a9e06f98ddb55b298f1a66bf94c6b has killed off any
use of this config option long ago.

Signed-off-by: Zoltan Devai <zdevai@gmail.com>
---
 arch/arm/Kconfig                    |    4 ----
 arch/mn10300/Kconfig                |    3 ---
 arch/tile/Kconfig                   |    3 ---
 arch/tile/configs/tilegx_defconfig  |    1 -
 arch/tile/configs/tilepro_defconfig |    1 -
 arch/um/defconfig                   |    1 -
 arch/xtensa/configs/iss_defconfig   |    1 -
 arch/xtensa/configs/s6105_defconfig |    1 -
 8 files changed, 0 insertions(+), 15 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c71a8f..37cc722 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -347,7 +347,6 @@ config ARCH_GEMINI
 config ARCH_PRIMA2
 	bool "CSR SiRFSoC PRIMA2 ARM Cortex A9 Platform"
 	select CPU_V7
-	select GENERIC_TIME
 	select NO_IOPORT
 	select GENERIC_CLOCKEVENTS
 	select CLKDEV_LOOKUP
@@ -520,7 +519,6 @@ config ARCH_LPC32XX
 	select ARM_AMBA
 	select USB_ARCH_HAS_OHCI
 	select CLKDEV_LOOKUP
-	select GENERIC_TIME
 	select GENERIC_CLOCKEVENTS
 	help
 	  Support for the NXP LPC32XX family of processors
@@ -599,7 +597,6 @@ config ARCH_TEGRA
 	bool "NVIDIA Tegra"
 	select CLKDEV_LOOKUP
 	select CLKSRC_MMIO
-	select GENERIC_TIME
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_GPIO
 	select HAVE_CLK
@@ -911,7 +908,6 @@ config ARCH_VT8500
 config ARCH_ZYNQ
 	bool "Xilinx Zynq ARM Cortex A9 Platform"
 	select CPU_V7
-	select GENERIC_TIME
 	select GENERIC_CLOCKEVENTS
 	select CLKDEV_LOOKUP
 	select ARM_GIC
diff --git a/arch/mn10300/Kconfig b/arch/mn10300/Kconfig
index 1f87034..5f7f2f8d 100644
--- a/arch/mn10300/Kconfig
+++ b/arch/mn10300/Kconfig
@@ -47,9 +47,6 @@ config GENERIC_CMOS_UPDATE
 config GENERIC_HWEIGHT
 	def_bool y
 
-config GENERIC_TIME
-	def_bool y
-
 config GENERIC_CLOCKEVENTS
 	def_bool y
 
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 0249b8b..4c5b286 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -45,9 +45,6 @@ config NEED_PER_CPU_PAGE_FIRST_CHUNK
 config SYS_SUPPORTS_HUGETLBFS
 	def_bool y
 
-config GENERIC_TIME
-	def_bool y
-
 config GENERIC_CLOCKEVENTS
 	def_bool y
 
diff --git a/arch/tile/configs/tilegx_defconfig b/arch/tile/configs/tilegx_defconfig
index 2ad73fb..dafdbba 100644
--- a/arch/tile/configs/tilegx_defconfig
+++ b/arch/tile/configs/tilegx_defconfig
@@ -11,7 +11,6 @@ CONFIG_HAVE_ARCH_ALLOC_REMAP=y
 CONFIG_HAVE_SETUP_PER_CPU_AREA=y
 CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
 CONFIG_SYS_SUPPORTS_HUGETLBFS=y
-CONFIG_GENERIC_TIME=y
 CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_RWSEM_GENERIC_SPINLOCK=y
 CONFIG_DEFAULT_MIGRATION_COST=10000000
diff --git a/arch/tile/configs/tilepro_defconfig b/arch/tile/configs/tilepro_defconfig
index f58dc36..6f05f969 100644
--- a/arch/tile/configs/tilepro_defconfig
+++ b/arch/tile/configs/tilepro_defconfig
@@ -11,7 +11,6 @@ CONFIG_HAVE_ARCH_ALLOC_REMAP=y
 CONFIG_HAVE_SETUP_PER_CPU_AREA=y
 CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
 CONFIG_SYS_SUPPORTS_HUGETLBFS=y
-CONFIG_GENERIC_TIME=y
 CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_RWSEM_GENERIC_SPINLOCK=y
 CONFIG_DEFAULT_MIGRATION_COST=10000000
diff --git a/arch/um/defconfig b/arch/um/defconfig
index 9f7634f..761f5e1 100644
--- a/arch/um/defconfig
+++ b/arch/um/defconfig
@@ -13,7 +13,6 @@ CONFIG_LOCKDEP_SUPPORT=y
 # CONFIG_STACKTRACE_SUPPORT is not set
 CONFIG_GENERIC_CALIBRATE_DELAY=y
 CONFIG_GENERIC_BUG=y
-CONFIG_GENERIC_TIME=y
 CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_IRQ_RELEASE_METHOD=y
 CONFIG_HZ=100
diff --git a/arch/xtensa/configs/iss_defconfig b/arch/xtensa/configs/iss_defconfig
index 0234cd1..f932b30 100644
--- a/arch/xtensa/configs/iss_defconfig
+++ b/arch/xtensa/configs/iss_defconfig
@@ -15,7 +15,6 @@ CONFIG_GENERIC_GPIO=y
 # CONFIG_ARCH_HAS_ILOG2_U64 is not set
 CONFIG_NO_IOPORT=y
 CONFIG_HZ=100
-CONFIG_GENERIC_TIME=y
 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
 CONFIG_CONSTRUCTORS=y
 
diff --git a/arch/xtensa/configs/s6105_defconfig b/arch/xtensa/configs/s6105_defconfig
index 4891abb..550e8ed 100644
--- a/arch/xtensa/configs/s6105_defconfig
+++ b/arch/xtensa/configs/s6105_defconfig
@@ -15,7 +15,6 @@ CONFIG_GENERIC_GPIO=y
 # CONFIG_ARCH_HAS_ILOG2_U64 is not set
 CONFIG_NO_IOPORT=y
 CONFIG_HZ=100
-CONFIG_GENERIC_TIME=y
 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
 
 #
-- 
1.7.4.1

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Sergei Shtylyov]

Hello.

On 30-07-2011 20:14, Zoltan Devai wrote:

> Commit 592913ecb87a9e06f98ddb55b298f1a66bf94c6b has killed off any

    Please also specify that commit's summry in parens.

> use of this config option long ago.

> Signed-off-by: Zoltan Devai<zdevai@gmail.com>

WBR, Sergei

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[richard -rw- weinberger]

On Sat, Jul 30, 2011 at 6:14 PM, Zoltan Devai <zdevai@gmail.com> wrote:
> Commit 592913ecb87a9e06f98ddb55b298f1a66bf94c6b has killed off any
> use of this config option long ago.
>
> Signed-off-by: Zoltan Devai <zdevai@gmail.com>

For arch/um/:
Acked-by: Richard Weinberger <richard@nod.at>

-- 
Thanks,
//richard

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Russell King - ARM Linux]

On Sat, Jul 30, 2011 at 06:14:38PM +0200, Zoltan Devai wrote:
> Commit 592913ecb87a9e06f98ddb55b298f1a66bf94c6b has killed off any
> use of this config option long ago.

I don't see the point of this - we were free of GENERIC_TIME on ARM
shortly after it was originally killed off.  The problem is you can't
stop people introducing new uses of this - because it existed once and
there's nothing which errors out on its presence, people are going to
continue submitting patches with it in.  And it's going to continue
being missed at the review stage.

I've a similar problem with folk on ARM including mach/gpio.h as their
sole gpio header file rather than linux/gpio.h - I've been trying for
the last 1-2 years to educate people to use linux/ in preference.  You
can't do it, and I'm still just about the only one who picks up on that.
(SoC maintainers don't care.)  They will end up caring when I push a
change during the next merge window though, so I'll eventually stop
mach/gpio.h being included.  (Instead, it'll be asm/gpio.h).

GENERIC_TIME though... I don't think you'll ever stop new uses of it
creeping in unless you can arrange for something to error out.

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Geert Uytterhoeven]

On Mon, Aug 1, 2011 at 10:36, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jul 30, 2011 at 06:14:38PM +0200, Zoltan Devai wrote:
>> Commit 592913ecb87a9e06f98ddb55b298f1a66bf94c6b has killed off any
>> use of this config option long ago.
>
> I don't see the point of this - we were free of GENERIC_TIME on ARM
> shortly after it was originally killed off. ?The problem is you can't
> stop people introducing new uses of this - because it existed once and
> there's nothing which errors out on its presence, people are going to
> continue submitting patches with it in. ?And it's going to continue
> being missed at the review stage.
>
> I've a similar problem with folk on ARM including mach/gpio.h as their
> sole gpio header file rather than linux/gpio.h - I've been trying for
> the last 1-2 years to educate people to use linux/ in preference. ?You
> can't do it, and I'm still just about the only one who picks up on that.
> (SoC maintainers don't care.) ?They will end up caring when I push a
> change during the next merge window though, so I'll eventually stop
> mach/gpio.h being included. ?(Instead, it'll be asm/gpio.h).
>
> GENERIC_TIME though... I don't think you'll ever stop new uses of it
> creeping in unless you can arrange for something to error out.

Doesn't kconf error out when trying to select a non-existent symbol?

Gr{oetje,eeting}s,

? ? ? ? ? ? ? ? ? ? ? ? Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Russell King - ARM Linux]

On Mon, Aug 01, 2011 at 12:09:02PM +0200, Geert Uytterhoeven wrote:
> On Mon, Aug 1, 2011 at 10:36, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Sat, Jul 30, 2011 at 06:14:38PM +0200, Zoltan Devai wrote:
> >> Commit 592913ecb87a9e06f98ddb55b298f1a66bf94c6b has killed off any
> >> use of this config option long ago.
> >
> > I don't see the point of this - we were free of GENERIC_TIME on ARM
> > shortly after it was originally killed off. ?The problem is you can't
> > stop people introducing new uses of this - because it existed once and
> > there's nothing which errors out on its presence, people are going to
> > continue submitting patches with it in. ?And it's going to continue
> > being missed at the review stage.
> >
> > I've a similar problem with folk on ARM including mach/gpio.h as their
> > sole gpio header file rather than linux/gpio.h - I've been trying for
> > the last 1-2 years to educate people to use linux/ in preference. ?You
> > can't do it, and I'm still just about the only one who picks up on that.
> > (SoC maintainers don't care.) ?They will end up caring when I push a
> > change during the next merge window though, so I'll eventually stop
> > mach/gpio.h being included. ?(Instead, it'll be asm/gpio.h).
> >
> > GENERIC_TIME though... I don't think you'll ever stop new uses of it
> > creeping in unless you can arrange for something to error out.
> 
> Doesn't kconf error out when trying to select a non-existent symbol?

Nope.

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Geert Uytterhoeven]

On Mon, Aug 1, 2011 at 12:14, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Aug 01, 2011 at 12:09:02PM +0200, Geert Uytterhoeven wrote:
>> On Mon, Aug 1, 2011 at 10:36, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Sat, Jul 30, 2011 at 06:14:38PM +0200, Zoltan Devai wrote:
>> >> Commit 592913ecb87a9e06f98ddb55b298f1a66bf94c6b has killed off any
>> >> use of this config option long ago.
>> >
>> > I don't see the point of this - we were free of GENERIC_TIME on ARM
>> > shortly after it was originally killed off. ?The problem is you can't
>> > stop people introducing new uses of this - because it existed once and
>> > there's nothing which errors out on its presence, people are going to
>> > continue submitting patches with it in. ?And it's going to continue
>> > being missed at the review stage.
>> >
>> > I've a similar problem with folk on ARM including mach/gpio.h as their
>> > sole gpio header file rather than linux/gpio.h - I've been trying for
>> > the last 1-2 years to educate people to use linux/ in preference. ?You
>> > can't do it, and I'm still just about the only one who picks up on that.
>> > (SoC maintainers don't care.) ?They will end up caring when I push a
>> > change during the next merge window though, so I'll eventually stop
>> > mach/gpio.h being included. ?(Instead, it'll be asm/gpio.h).
>> >
>> > GENERIC_TIME though... I don't think you'll ever stop new uses of it
>> > creeping in unless you can arrange for something to error out.
>>
>> Doesn't kconf error out when trying to select a non-existent symbol?
>
> Nope.

You're right. So that's a bug.

Gr{oetje,eeting}s,

? ? ? ? ? ? ? ? ? ? ? ? Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Uwe Kleine-König]

On Mon, Aug 01, 2011 at 01:27:52PM +0200, Geert Uytterhoeven wrote:
> On Mon, Aug 1, 2011 at 12:14, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Aug 01, 2011 at 12:09:02PM +0200, Geert Uytterhoeven wrote:
> >> Doesn't kconf error out when trying to select a non-existent symbol?
> >
> > Nope.
> 
> You're right. So that's a bug.
Not sure, this might have been done on purpose to make cross-tree series
easier!?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Arnaud Lacombe]

Hi,

On Mon, Aug 1, 2011 at 7:27 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Aug 1, 2011 at 12:14, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Mon, Aug 01, 2011 at 12:09:02PM +0200, Geert Uytterhoeven wrote:
>>> On Mon, Aug 1, 2011 at 10:36, Russell King - ARM Linux
>>> <linux@arm.linux.org.uk> wrote:
>>> > On Sat, Jul 30, 2011 at 06:14:38PM +0200, Zoltan Devai wrote:
>>> >> Commit 592913ecb87a9e06f98ddb55b298f1a66bf94c6b has killed off any
>>> >> use of this config option long ago.
>>> >
>>> > I don't see the point of this - we were free of GENERIC_TIME on ARM
>>> > shortly after it was originally killed off. ?The problem is you can't
>>> > stop people introducing new uses of this - because it existed once and
>>> > there's nothing which errors out on its presence, people are going to
>>> > continue submitting patches with it in. ?And it's going to continue
>>> > being missed at the review stage.
>>> >
>>> > I've a similar problem with folk on ARM including mach/gpio.h as their
>>> > sole gpio header file rather than linux/gpio.h - I've been trying for
>>> > the last 1-2 years to educate people to use linux/ in preference. ?You
>>> > can't do it, and I'm still just about the only one who picks up on that.
>>> > (SoC maintainers don't care.) ?They will end up caring when I push a
>>> > change during the next merge window though, so I'll eventually stop
>>> > mach/gpio.h being included. ?(Instead, it'll be asm/gpio.h).
>>> >
>>> > GENERIC_TIME though... I don't think you'll ever stop new uses of it
>>> > creeping in unless you can arrange for something to error out.
>>>
>>> Doesn't kconf error out when trying to select a non-existent symbol?
>>
>> Nope.
>
> You're right. So that's a bug.
>
depends on what you are trying to achieve and what the problem is.

Internally kconfig will create a dummy symbol when it encounter a
missing symbol so that arch/arm/Kconfig can reference a symbol which
will be fully defined later on. I do not think you want to forward
decl all the symbol which can be used. That'd be a mess. That said, we
can come with a form of symbol deprecation that would error-out when
used.

 - Arnaud

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Kyle Moffett]

On Mon, Aug 1, 2011 at 11:04, Arnaud Lacombe <lacombar@gmail.com> wrote:
> Hi,
>
> On Mon, Aug 1, 2011 at 7:27 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Mon, Aug 1, 2011 at 12:14, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Mon, Aug 01, 2011 at 12:09:02PM +0200, Geert Uytterhoeven wrote:
>>>> On Mon, Aug 1, 2011 at 10:36, Russell King - ARM Linux
>>>> <linux@arm.linux.org.uk> wrote:
>>>> > On Sat, Jul 30, 2011 at 06:14:38PM +0200, Zoltan Devai wrote:
>>>> >> Commit 592913ecb87a9e06f98ddb55b298f1a66bf94c6b has killed off any
>>>> >> use of this config option long ago.
>>>> >
>>>> > I don't see the point of this - we were free of GENERIC_TIME on ARM
>>>> > shortly after it was originally killed off. ?The problem is you can't
>>>> > stop people introducing new uses of this - because it existed once and
>>>> > there's nothing which errors out on its presence, people are going to
>>>> > continue submitting patches with it in. ?And it's going to continue
>>>> > being missed at the review stage.
>>>> >
>>>> > I've a similar problem with folk on ARM including mach/gpio.h as their
>>>> > sole gpio header file rather than linux/gpio.h - I've been trying for
>>>> > the last 1-2 years to educate people to use linux/ in preference. ?You
>>>> > can't do it, and I'm still just about the only one who picks up on that.
>>>> > (SoC maintainers don't care.) ?They will end up caring when I push a
>>>> > change during the next merge window though, so I'll eventually stop
>>>> > mach/gpio.h being included. ?(Instead, it'll be asm/gpio.h).
>>>> >
>>>> > GENERIC_TIME though... I don't think you'll ever stop new uses of it
>>>> > creeping in unless you can arrange for something to error out.
>>>>
>>>> Doesn't kconf error out when trying to select a non-existent symbol?
>>>
>>> Nope.
>>
>> You're right. So that's a bug.
>>
> depends on what you are trying to achieve and what the problem is.
>
> Internally kconfig will create a dummy symbol when it encounter a
> missing symbol so that arch/arm/Kconfig can reference a symbol which
> will be fully defined later on. I do not think you want to forward
> decl all the symbol which can be used. That'd be a mess. That said, we
> can come with a form of symbol deprecation that would error-out when
> used.

Would it be possible instead to make Kconfig go through all the symbols
after everything is processed and identify any remaining "dummy symbols"
which were not actually declared anywhere?

Right now if you typo a "select" statement you get no warnings that you
are selecting something that does not exist, which is probably a cause
of many kinds of errors beyond this particular one.

Cheers,
Kyle Moffett

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Arnaud Lacombe]

Hi,

On Mon, Aug 1, 2011 at 11:15 AM, Kyle Moffett <kyle@moffetthome.net> wrote:
> On Mon, Aug 1, 2011 at 11:04, Arnaud Lacombe <lacombar@gmail.com> wrote:
>> Hi,
>>
>> On Mon, Aug 1, 2011 at 7:27 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> On Mon, Aug 1, 2011 at 12:14, Russell King - ARM Linux
>>>>>[...]
>>>>>
>>>>> Doesn't kconf error out when trying to select a non-existent symbol?
>>>>
>>>> Nope.
>>>
>>> You're right. So that's a bug.
>>>
>> depends on what you are trying to achieve and what the problem is.
>>
>> Internally kconfig will create a dummy symbol when it encounter a
>> missing symbol so that arch/arm/Kconfig can reference a symbol which
>> will be fully defined later on. I do not think you want to forward
>> decl all the symbol which can be used. That'd be a mess. That said, we
>> can come with a form of symbol deprecation that would error-out when
>> used.
>
> Would it be possible instead to make Kconfig go through all the symbols
> after everything is processed and identify any remaining "dummy symbols"
> which were not actually declared anywhere?
>
this is software, everything is possible.

> Right now if you typo a "select" statement you get no warnings that you
> are selecting something that does not exist, which is probably a cause
> of many kinds of errors beyond this particular one.
>
d'oh! ... I'm not sure we want that. Dummy symbol are heavily used
internally, a trivial implementation[0] triggered:

% make REGENERATE_PARSERS=y alldefconfig 2>&1 | grep 'defined without
type' | wc -l
817

Moreover, this approach is deemed to fail. The current symbol
namespace is tied to an arch, so whenever you do:

arch/arm/Kconfig:
config FOO
    bool

config BAZ
    bool

drivers/cpufreq/Kconfig
config BAR
    depends on ARM && FOO
    select BAZ

You will end up triggering the warning for every ARCH != ARM...

 - Arnaud

[0]: or rather a fix as we currently only do the check for symbol linked to menu

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Nicolas Pitre]

On Mon, 1 Aug 2011, Arnaud Lacombe wrote:

> Moreover, this approach is deemed to fail. The current symbol
> namespace is tied to an arch, so whenever you do:
> 
> arch/arm/Kconfig:
> config FOO
>     bool
> 
> config BAZ
>     bool
> 
> drivers/cpufreq/Kconfig
> config BAR
>     depends on ARM && FOO
>     select BAZ
> 
> You will end up triggering the warning for every ARCH != ARM...

You can keep a state for those symbols with regard to their level of 
reference.  Surely if ARM isn't true, BAZ is not "actively" referenced 
in the end.


Nicolas

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Arnaud Lacombe]

Hi,

On Mon, Aug 1, 2011 at 12:40 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 1 Aug 2011, Arnaud Lacombe wrote:
>
>> Moreover, this approach is deemed to fail. The current symbol
>> namespace is tied to an arch, so whenever you do:
>>
>> arch/arm/Kconfig:
>> config FOO
>> ? ? bool
>>
>> config BAZ
>> ? ? bool
>>
>> drivers/cpufreq/Kconfig
>> config BAR
>> ? ? depends on ARM && FOO
>> ? ? select BAZ
>>
>> You will end up triggering the warning for every ARCH != ARM...
>
> You can keep a state for those symbols with regard to their level of
> reference. ?Surely if ARM isn't true, BAZ is not "actively" referenced
> in the end.
>
he :) we enter in compilers optimizations. As much as I agree with
you, that might not be trivial to implement given the internal,
ad-hoc, structure of kconfig. All of that would be useless if we had a
single global namespace.

 - Arnaud

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Kyle Moffett]

On Mon, Aug 1, 2011 at 12:08, Arnaud Lacombe <lacombar@gmail.com> wrote:
> On Mon, Aug 1, 2011 at 11:15 AM, Kyle Moffett <kyle@moffetthome.net> wrote:
>> On Mon, Aug 1, 2011 at 11:04, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>> On Mon, Aug 1, 2011 at 7:27 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>> On Mon, Aug 1, 2011 at 12:14, Russell King - ARM Linux
>>>>>>[...]
>>>>>>
>>>>>> Doesn't kconf error out when trying to select a non-existent symbol?
>>>>>
>>>>> Nope.
>>>>
>>>> You're right. So that's a bug.
>>>>
>>> depends on what you are trying to achieve and what the problem is.
>>>
>>> Internally kconfig will create a dummy symbol when it encounter a
>>> missing symbol so that arch/arm/Kconfig can reference a symbol which
>>> will be fully defined later on. I do not think you want to forward
>>> decl all the symbol which can be used. That'd be a mess. That said, we
>>> can come with a form of symbol deprecation that would error-out when
>>> used.
>>
>> Would it be possible instead to make Kconfig go through all the symbols
>> after everything is processed and identify any remaining "dummy symbols"
>> which were not actually declared anywhere?
>>
> this is software, everything is possible.
>
>> Right now if you typo a "select" statement you get no warnings that you
>> are selecting something that does not exist, which is probably a cause
>> of many kinds of errors beyond this particular one.
>>
> d'oh! ... I'm not sure we want that. Dummy symbol are heavily used
> internally, a trivial implementation[0] triggered:
>
> % make REGENERATE_PARSERS=y alldefconfig 2>&1 | grep 'defined without
> type' | wc -l
> 817
>
> Moreover, this approach is deemed to fail. The current symbol
> namespace is tied to an arch, so whenever you do:
>
> arch/arm/Kconfig:
> config FOO
> ? ?bool
>
> config BAZ
> ? ?bool
>
> drivers/cpufreq/Kconfig
> config BAR
> ? ?depends on ARM && FOO
> ? ?select BAZ
>
> You will end up triggering the warning for every ARCH != ARM...

Perhaps that's an argument for building a single Kconfig namespace?
At the very least, most of the architecture-generic warnings could be
worked around with trivial predeclarations in an "arch/Kconfig" file:

config ARM
        bool
[...]
config X86
        bool

There's probably technical issues that I'm missing that would make
that inordinately painful, but I can't see them right now... any ideas?

Cheers,
Kyle Moffett

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Arnaud Lacombe]

Hi,

On Mon, Aug 1, 2011 at 12:48 PM, Kyle Moffett <kyle@moffetthome.net> wrote:
> On Mon, Aug 1, 2011 at 12:08, Arnaud Lacombe <lacombar@gmail.com> wrote:
>> On Mon, Aug 1, 2011 at 11:15 AM, Kyle Moffett <kyle@moffetthome.net> wrote:
>>> On Mon, Aug 1, 2011 at 11:04, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>>> On Mon, Aug 1, 2011 at 7:27 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>>> On Mon, Aug 1, 2011 at 12:14, Russell King - ARM Linux
>>>>>>>[...]
>>>>>>>
>>>>>>> Doesn't kconf error out when trying to select a non-existent symbol?
>>>>>>
>>>>>> Nope.
>>>>>
>>>>> You're right. So that's a bug.
>>>>>
>>>> depends on what you are trying to achieve and what the problem is.
>>>>
>>>> Internally kconfig will create a dummy symbol when it encounter a
>>>> missing symbol so that arch/arm/Kconfig can reference a symbol which
>>>> will be fully defined later on. I do not think you want to forward
>>>> decl all the symbol which can be used. That'd be a mess. That said, we
>>>> can come with a form of symbol deprecation that would error-out when
>>>> used.
>>>
>>> Would it be possible instead to make Kconfig go through all the symbols
>>> after everything is processed and identify any remaining "dummy symbols"
>>> which were not actually declared anywhere?
>>>
>> this is software, everything is possible.
>>
>>> Right now if you typo a "select" statement you get no warnings that you
>>> are selecting something that does not exist, which is probably a cause
>>> of many kinds of errors beyond this particular one.
>>>
>> d'oh! ... I'm not sure we want that. Dummy symbol are heavily used
>> internally, a trivial implementation[0] triggered:
>>
>> % make REGENERATE_PARSERS=y alldefconfig 2>&1 | grep 'defined without
>> type' | wc -l
>> 817
>>
>> Moreover, this approach is deemed to fail. The current symbol
>> namespace is tied to an arch, so whenever you do:
>>
>> arch/arm/Kconfig:
>> config FOO
>> ? ?bool
>>
>> config BAZ
>> ? ?bool
>>
>> drivers/cpufreq/Kconfig
>> config BAR
>> ? ?depends on ARM && FOO
>> ? ?select BAZ
>>
>> You will end up triggering the warning for every ARCH != ARM...
>
> Perhaps that's an argument for building a single Kconfig namespace?
I'm working on that, but this is a real mess :)

> At the very least, most of the architecture-generic warnings could be
> worked around with trivial predeclarations in an "arch/Kconfig" file:
>
> config ARM
> ? ? ? ?bool
> [...]
> config X86
> ? ? ? ?bool
>
> There's probably technical issues that I'm missing that would make
> that inordinately painful, but I can't see them right now... any ideas?
>
not I directly forsee.

 - Arnaud

> Cheers,
> Kyle Moffett
>

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Arnaud Lacombe]

Hi,

On Mon, Aug 1, 2011 at 12:08 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> Hi,
>
> On Mon, Aug 1, 2011 at 11:15 AM, Kyle Moffett <kyle@moffetthome.net> wrote:
>> On Mon, Aug 1, 2011 at 11:04, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>> Hi,
>>>
>>> On Mon, Aug 1, 2011 at 7:27 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>> On Mon, Aug 1, 2011 at 12:14, Russell King - ARM Linux
>>>>>>[...]
>>>>>>
>>>>>> Doesn't kconf error out when trying to select a non-existent symbol?
>>>>>
>>>>> Nope.
>>>>
>>>> You're right. So that's a bug.
>>>>
>>> depends on what you are trying to achieve and what the problem is.
>>>
>>> Internally kconfig will create a dummy symbol when it encounter a
>>> missing symbol so that arch/arm/Kconfig can reference a symbol which
>>> will be fully defined later on. I do not think you want to forward
>>> decl all the symbol which can be used. That'd be a mess. That said, we
>>> can come with a form of symbol deprecation that would error-out when
>>> used.
>>
>> Would it be possible instead to make Kconfig go through all the symbols
>> after everything is processed and identify any remaining "dummy symbols"
>> which were not actually declared anywhere?
>>
> this is software, everything is possible.
>
>> Right now if you typo a "select" statement you get no warnings that you
>> are selecting something that does not exist, which is probably a cause
>> of many kinds of errors beyond this particular one.
>>
> d'oh! ... I'm not sure we want that. Dummy symbol are heavily used
> internally, a trivial implementation[0] triggered:
>
> % make REGENERATE_PARSERS=y alldefconfig 2>&1 | grep 'defined without
> type' | wc -l
> 817
>
> Moreover, this approach is deemed to fail. The current symbol
> namespace is tied to an arch, so whenever you do:
>
> arch/arm/Kconfig:
> config FOO
> ? ?bool
>
> config BAZ
> ? ?bool
>
> drivers/cpufreq/Kconfig
> config BAR
> ? ?depends on ARM && FOO
> ? ?select BAZ
>
> You will end up triggering the warning for every ARCH != ARM...
>
Ok, I restricted the tagging to selected symbol, and we definitively
have this pattern occurring. It shall be fixed when/if we ends up
having a global configuration namespace.

I think I can work a patch.

 - Arnaud

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Zoltan Devai]

2011/8/1 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Sat, Jul 30, 2011 at 06:14:38PM +0200, Zoltan Devai wrote:
>> Commit 592913ecb87a9e06f98ddb55b298f1a66bf94c6b has killed off any
>> use of this config option long ago.
>
> I don't see the point of this - we were free of GENERIC_TIME on ARM
> shortly after it was originally killed off. ?The problem is you can't
> stop people introducing new uses of this - because it existed once and
> there's nothing which errors out on its presence, people are going to
> continue submitting patches with it in. ?And it's going to continue
> being missed at the review stage.
>
> I've a similar problem with folk on ARM including mach/gpio.h as their
> sole gpio header file rather than linux/gpio.h - I've been trying for
> the last 1-2 years to educate people to use linux/ in preference. ?You
> can't do it, and I'm still just about the only one who picks up on that.
> (SoC maintainers don't care.) ?They will end up caring when I push a
> change during the next merge window though, so I'll eventually stop
> mach/gpio.h being included. ?(Instead, it'll be asm/gpio.h).
>
> GENERIC_TIME though... I don't think you'll ever stop new uses of it
> creeping in unless you can arrange for something to error out.

Sure, but the patch at least reduces the chances of copy-pasting it,
and makes it obvious by a simple grep that there's no use of it at all,
so I still think it's wort merging.

Don't know though who should pick this up...

Z

[PATCH] Remove remaining references of CONFIG_GENERIC_TIME

[Russell King - ARM Linux]

On Mon, Aug 01, 2011 at 01:41:32PM +0200, Zoltan Devai wrote:
> 2011/8/1 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > On Sat, Jul 30, 2011 at 06:14:38PM +0200, Zoltan Devai wrote:
> >> Commit 592913ecb87a9e06f98ddb55b298f1a66bf94c6b has killed off any
> >> use of this config option long ago.
> >
> > I don't see the point of this - we were free of GENERIC_TIME on ARM
> > shortly after it was originally killed off. ?The problem is you can't
> > stop people introducing new uses of this - because it existed once and
> > there's nothing which errors out on its presence, people are going to
> > continue submitting patches with it in. ?And it's going to continue
> > being missed at the review stage.
> >
> > I've a similar problem with folk on ARM including mach/gpio.h as their
> > sole gpio header file rather than linux/gpio.h - I've been trying for
> > the last 1-2 years to educate people to use linux/ in preference. ?You
> > can't do it, and I'm still just about the only one who picks up on that.
> > (SoC maintainers don't care.) ?They will end up caring when I push a
> > change during the next merge window though, so I'll eventually stop
> > mach/gpio.h being included. ?(Instead, it'll be asm/gpio.h).
> >
> > GENERIC_TIME though... I don't think you'll ever stop new uses of it
> > creeping in unless you can arrange for something to error out.
> 
> Sure, but the patch at least reduces the chances of copy-pasting it,
> and makes it obvious by a simple grep that there's no use of it at all,
> so I still think it's wort merging.

That argument doesn't work - as can be seen from my first paragraph.
The fact that we have new references to it in arch/arm/Kconfig is
proof of that.