In -test4 I have:
CONFIG_SERIO=m
CONFIG_SERIO_I8042=m
CONFIG_SERIO_SERPORT=m
CONFIG_SERIO_CT82C710=m
CONFIG_SERIO_PARKBD=m
CONFIG_SERIO_PCIPS2=m
but -test5 insists on:
CONFIG_SERIO=m
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
CONFIG_SERIO_CT82C710=m
CONFIG_SERIO_PARKBD=m
CONFIG_SERIO_PCIPS2=m
Removing the I8042 line and doing 'make oldconfig' does not even
ask about it but sets it to '=y'. As a result I get:
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o: In function `atkbd_interrupt':
drivers/built-in.o(.text+0x6d10f): undefined reference to `serio_rescan'
drivers/built-in.o: In function `atkbd_disconnect':
drivers/built-in.o(.text+0x6d726): undefined reference to `serio_close'
drivers/built-in.o: In function `atkbd_connect':
drivers/built-in.o(.text+0x6d84e): undefined reference to `serio_open'
drivers/built-in.o(.text+0x6d883): undefined reference to `serio_close'
drivers/built-in.o: In function `atkbd_init':
drivers/built-in.o(.init.text+0x5fd6): undefined reference to
`serio_register_de
vice'
drivers/built-in.o: In function `atkbd_exit':
drivers/built-in.o(.exit.text+0x196): undefined reference to
`serio_unregister_d
evice'
make: *** [.tmp_vmlinux1] Error 1
--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>
On Tue, Sep 09, 2003 at 09:40:15PM +1000, Eyal Lebedinsky wrote:
>...
In -test4 I have:
>
> CONFIG_SERIO=m
> CONFIG_SERIO_I8042=m
> CONFIG_SERIO_SERPORT=m
> CONFIG_SERIO_CT82C710=m
> CONFIG_SERIO_PARKBD=m
> CONFIG_SERIO_PCIPS2=m
>
> but -test5 insists on:
>
> CONFIG_SERIO=m
> CONFIG_SERIO_I8042=y
> CONFIG_SERIO_SERPORT=m
> CONFIG_SERIO_CT82C710=m
> CONFIG_SERIO_PARKBD=m
> CONFIG_SERIO_PCIPS2=m
>
> Removing the I8042 line and doing 'make oldconfig' does not even
> ask about it but sets it to '=y'. As a result I get:
>
> LD init/built-in.o
> LD .tmp_vmlinux1
> drivers/built-in.o: In function `atkbd_interrupt':
> drivers/built-in.o(.text+0x6d10f): undefined reference to `serio_rescan'
> drivers/built-in.o: In function `atkbd_disconnect':
> drivers/built-in.o(.text+0x6d726): undefined reference to `serio_close'
> drivers/built-in.o: In function `atkbd_connect':
> drivers/built-in.o(.text+0x6d84e): undefined reference to `serio_open'
> drivers/built-in.o(.text+0x6d883): undefined reference to `serio_close'
> drivers/built-in.o: In function `atkbd_init':
> drivers/built-in.o(.init.text+0x5fd6): undefined reference to
> `serio_register_de
> vice'
> drivers/built-in.o: In function `atkbd_exit':
> drivers/built-in.o(.exit.text+0x196): undefined reference to
> `serio_unregister_d
> evice'
> make: *** [.tmp_vmlinux1] Error 1
The patch below should fix it.
cu
Adrian
--- linux-2.6.0-test4-mm5-modular-no-smp/drivers/input/keyboard/Kconfig.old 2003-09-04 19:03:45.000000000 +0200
+++ linux-2.6.0-test4-mm5-modular-no-smp/drivers/input/keyboard/Kconfig 2003-09-04 19:04:49.000000000 +0200
@@ -13,7 +13,8 @@
config KEYBOARD_ATKBD
tristate "AT keyboard support" if EMBEDDED || !X86
- default y
+ default y if INPUT=y && INPUT_KEYBOARD=y && SERIO=y
+ default m
depends on INPUT && INPUT_KEYBOARD && SERIO
help
Say Y here if you want to use a standard AT or PS/2 keyboard. Usually
--- linux-2.6.0-test5+tr-modular-no-smp/drivers/input/serio/Kconfig.old 2003-09-10 12:52:22.000000000 +0200
+++ linux-2.6.0-test5+tr-modular-no-smp/drivers/input/serio/Kconfig 2003-09-10 12:52:47.000000000 +0200
@@ -20,7 +20,8 @@
config SERIO_I8042
tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
- default y
+ default y if SERIO=y
+ default m
depends on SERIO
---help---
i8042 is the chip over which the standard AT keyboard and PS/2
On Wednesday 10 September 2003 13:02, Adrian Bunk wrote:
> On Tue, Sep 09, 2003 at 09:40:15PM +1000, Eyal Lebedinsky wrote:
> >...
>
> In -test4 I have:
> > CONFIG_SERIO=m
> > CONFIG_SERIO_I8042=m
> > CONFIG_SERIO_SERPORT=m
> > CONFIG_SERIO_CT82C710=m
> > CONFIG_SERIO_PARKBD=m
> > CONFIG_SERIO_PCIPS2=m
> >
> > but -test5 insists on:
> >
> > CONFIG_SERIO=m
> > CONFIG_SERIO_I8042=y
> > CONFIG_SERIO_SERPORT=m
> > CONFIG_SERIO_CT82C710=m
> > CONFIG_SERIO_PARKBD=m
> > CONFIG_SERIO_PCIPS2=m
> >
> > Removing the I8042 line and doing 'make oldconfig' does not even
> > ask about it but sets it to '=y'. As a result I get:
> > [...]
This is correct behaviour. Nobody building his kernel for a pc will ever want
his keyboard not to function until the module is loaded; the
CONFIG_SERIO_I8042 option is really only there for embedded devices based on
x86 processors which don't have an i8042 keyboard controller, which is where
the EMBEDDED option was made for. Modularizing this would effectively disable
the possibility of booting with init=/bin/sh.
Sytse
> [patch...]
On Wed, Sep 10, 2003 at 01:02:25PM +0200, Adrian Bunk wrote:
> The patch below should fix it.
I'm confused why you're copying me and not Vojtech.
--
Russell King ([email protected]) http://www.arm.linux.org.uk/personal/
Linux kernel maintainer of:
2.6 ARM Linux - http://www.arm.linux.org.uk/
2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Wed, Sep 10, 2003 at 03:01:56PM +0100, Russell King wrote:
> On Wed, Sep 10, 2003 at 01:02:25PM +0200, Adrian Bunk wrote:
> > The patch below should fix it.
>
> I'm confused why you're copying me and not Vojtech.
The "serio" confused me...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Sep 10, 2003 at 01:02:25PM +0200, Adrian Bunk wrote:
> On Tue, Sep 09, 2003 at 09:40:15PM +1000, Eyal Lebedinsky wrote:
> >...
> In -test4 I have:
> >
> > CONFIG_SERIO=m
> > CONFIG_SERIO_I8042=m
> > CONFIG_SERIO_SERPORT=m
> > CONFIG_SERIO_CT82C710=m
> > CONFIG_SERIO_PARKBD=m
> > CONFIG_SERIO_PCIPS2=m
> >
> > but -test5 insists on:
> >
> > CONFIG_SERIO=m
> > CONFIG_SERIO_I8042=y
> > CONFIG_SERIO_SERPORT=m
> > CONFIG_SERIO_CT82C710=m
> > CONFIG_SERIO_PARKBD=m
> > CONFIG_SERIO_PCIPS2=m
> >
> > Removing the I8042 line and doing 'make oldconfig' does not even
> > ask about it but sets it to '=y'. As a result I get:
> >
> > LD init/built-in.o
> > LD .tmp_vmlinux1
> > drivers/built-in.o: In function `atkbd_interrupt':
> > drivers/built-in.o(.text+0x6d10f): undefined reference to `serio_rescan'
> > drivers/built-in.o: In function `atkbd_disconnect':
> > drivers/built-in.o(.text+0x6d726): undefined reference to `serio_close'
> > drivers/built-in.o: In function `atkbd_connect':
> > drivers/built-in.o(.text+0x6d84e): undefined reference to `serio_open'
> > drivers/built-in.o(.text+0x6d883): undefined reference to `serio_close'
> > drivers/built-in.o: In function `atkbd_init':
> > drivers/built-in.o(.init.text+0x5fd6): undefined reference to
> > `serio_register_de
> > vice'
> > drivers/built-in.o: In function `atkbd_exit':
> > drivers/built-in.o(.exit.text+0x196): undefined reference to
> > `serio_unregister_d
> > evice'
> > make: *** [.tmp_vmlinux1] Error 1
>
> The patch below should fix it.
>
> cu
> Adrian
>
> --- linux-2.6.0-test4-mm5-modular-no-smp/drivers/input/keyboard/Kconfig.old 2003-09-04 19:03:45.000000000 +0200
> +++ linux-2.6.0-test4-mm5-modular-no-smp/drivers/input/keyboard/Kconfig 2003-09-04 19:04:49.000000000 +0200
> @@ -13,7 +13,8 @@
>
> config KEYBOARD_ATKBD
> tristate "AT keyboard support" if EMBEDDED || !X86
> - default y
> + default y if INPUT=y && INPUT_KEYBOARD=y && SERIO=y
> + default m
> depends on INPUT && INPUT_KEYBOARD && SERIO
> help
> Say Y here if you want to use a standard AT or PS/2 keyboard. Usually
> --- linux-2.6.0-test5+tr-modular-no-smp/drivers/input/serio/Kconfig.old 2003-09-10 12:52:22.000000000 +0200
> +++ linux-2.6.0-test5+tr-modular-no-smp/drivers/input/serio/Kconfig 2003-09-10 12:52:47.000000000 +0200
> @@ -20,7 +20,8 @@
>
> config SERIO_I8042
> tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
> - default y
> + default y if SERIO=y
> + default m
> depends on SERIO
> ---help---
> i8042 is the chip over which the standard AT keyboard and PS/2
A slightly better fix is for SERIO to default to Y on X86 and to
'select SERIO_I8042 if X86'. Then have INPUT_KEYBOARD similarly select
KEYBOARD_ATKBD.
Or, IMHO, even better would be my patch to remove EMBEDDED and replace
it with STANDARD || NONSTD_ABI which also fixes the wierd uses of
EMBEDDED we have now.
--
Tom Rini
http://gate.crashing.org/~trini/
On Wed, Sep 10, 2003 at 08:55:42AM -0700, Tom Rini wrote:
>...
> > --- linux-2.6.0-test4-mm5-modular-no-smp/drivers/input/keyboard/Kconfig.old 2003-09-04 19:03:45.000000000 +0200
> > +++ linux-2.6.0-test4-mm5-modular-no-smp/drivers/input/keyboard/Kconfig 2003-09-04 19:04:49.000000000 +0200
> > @@ -13,7 +13,8 @@
> >
> > config KEYBOARD_ATKBD
> > tristate "AT keyboard support" if EMBEDDED || !X86
> > - default y
> > + default y if INPUT=y && INPUT_KEYBOARD=y && SERIO=y
> > + default m
> > depends on INPUT && INPUT_KEYBOARD && SERIO
> > help
> > Say Y here if you want to use a standard AT or PS/2 keyboard. Usually
> > --- linux-2.6.0-test5+tr-modular-no-smp/drivers/input/serio/Kconfig.old 2003-09-10 12:52:22.000000000 +0200
> > +++ linux-2.6.0-test5+tr-modular-no-smp/drivers/input/serio/Kconfig 2003-09-10 12:52:47.000000000 +0200
> > @@ -20,7 +20,8 @@
> >
> > config SERIO_I8042
> > tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
> > - default y
> > + default y if SERIO=y
> > + default m
> > depends on SERIO
> > ---help---
> > i8042 is the chip over which the standard AT keyboard and PS/2
>
> A slightly better fix is for SERIO to default to Y on X86 and to
> 'select SERIO_I8042 if X86'. Then have INPUT_KEYBOARD similarly select
> KEYBOARD_ATKBD.
>...
That wouldn't be needed. AFAIK there are _no_ problems if SERIO=y, the
select you suggest is already implemented the other way round.
If SERIO is always y if !EMBEDDED || X86 my patch wouldn't be needed.
Considering this, it seems the patch below is both the best and the
simplest solution for most users.
It doesn't obsolete the other patch since SERIO=m is still possible, but
makes it more unlikely to accidentially set SERIO=m (or even SERIO=n).
> Tom Rini
cu
Adrian
--- linux-2.6.0-test5+tr-modular-no-smp/drivers/input/serio/Kconfig.old 2003-09-10 19:02:01.000000000 +0200
+++ linux-2.6.0-test5+tr-modular-no-smp/drivers/input/serio/Kconfig 2003-09-10 19:02:29.000000000 +0200
@@ -2,7 +2,7 @@
# Input core configuration
#
config SERIO
- tristate "Serial i/o support (needed for keyboard and mouse)"
+ tristate "Serial i/o support (needed for keyboard and mouse)" if EMBEDDED || !X86
default y
---help---
Say Yes here if you have any input device that uses serial I/O to
On Wed, Sep 10, 2003 at 07:06:11PM +0200, Adrian Bunk wrote:
> On Wed, Sep 10, 2003 at 08:55:42AM -0700, Tom Rini wrote:
> >...
> > > --- linux-2.6.0-test4-mm5-modular-no-smp/drivers/input/keyboard/Kconfig.old 2003-09-04 19:03:45.000000000 +0200
> > > +++ linux-2.6.0-test4-mm5-modular-no-smp/drivers/input/keyboard/Kconfig 2003-09-04 19:04:49.000000000 +0200
> > > @@ -13,7 +13,8 @@
> > >
> > > config KEYBOARD_ATKBD
> > > tristate "AT keyboard support" if EMBEDDED || !X86
> > > - default y
> > > + default y if INPUT=y && INPUT_KEYBOARD=y && SERIO=y
> > > + default m
> > > depends on INPUT && INPUT_KEYBOARD && SERIO
> > > help
> > > Say Y here if you want to use a standard AT or PS/2 keyboard. Usually
> > > --- linux-2.6.0-test5+tr-modular-no-smp/drivers/input/serio/Kconfig.old 2003-09-10 12:52:22.000000000 +0200
> > > +++ linux-2.6.0-test5+tr-modular-no-smp/drivers/input/serio/Kconfig 2003-09-10 12:52:47.000000000 +0200
> > > @@ -20,7 +20,8 @@
> > >
> > > config SERIO_I8042
> > > tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
> > > - default y
> > > + default y if SERIO=y
> > > + default m
> > > depends on SERIO
> > > ---help---
> > > i8042 is the chip over which the standard AT keyboard and PS/2
> >
> > A slightly better fix is for SERIO to default to Y on X86 and to
> > 'select SERIO_I8042 if X86'. Then have INPUT_KEYBOARD similarly select
> > KEYBOARD_ATKBD.
> >...
>
> That wouldn't be needed. AFAIK there are _no_ problems if SERIO=y, the
> select you suggest is already implemented the other way round.
The problem is that SERIO==y means that SERIO_I8042 must be Y, as you
ran into. If you have SERIO only asked on EMBEDDED || !X86, and on
similar conditions you then select SERIO_I8042, it just works.
> If SERIO is always y if !EMBEDDED || X86 my patch wouldn't be needed.
Correct. I was suggesting that you do:
tristate "Serial i/o support (needed for keyboard and mouse)" if
!EMBEDDED || !X86 (or so)
select SERIO_I8042 if X86 && !EMBEDDED
and then remove the conditions on SERIO_I8042, which puts all of the
auto-select-this magic in one spot.
--
Tom Rini
http://gate.crashing.org/~trini/
On Wed, Sep 10, 2003 at 11:59:02AM -0700, Tom Rini wrote:
> >
> > That wouldn't be needed. AFAIK there are _no_ problems if SERIO=y, the
> > select you suggest is already implemented the other way round.
>
> The problem is that SERIO==y means that SERIO_I8042 must be Y, as you
> ran into. If you have SERIO only asked on EMBEDDED || !X86, and on
> similar conditions you then select SERIO_I8042, it just works.
No the problems occur when SERIO=m.
> > If SERIO is always y if !EMBEDDED || X86 my patch wouldn't be needed.
>
> Correct. I was suggesting that you do:
> tristate "Serial i/o support (needed for keyboard and mouse)" if
> !EMBEDDED || !X86 (or so)
> select SERIO_I8042 if X86 && !EMBEDDED
>
> and then remove the conditions on SERIO_I8042, which puts all of the
> auto-select-this magic in one spot.
I can't see how this should work in all cases.
Could you send how you'd like to formulate this?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Sep 10, 2003 at 09:10:39PM +0200, Adrian Bunk wrote:
> On Wed, Sep 10, 2003 at 11:59:02AM -0700, Tom Rini wrote:
> > >
> > > That wouldn't be needed. AFAIK there are _no_ problems if SERIO=y, the
> > > select you suggest is already implemented the other way round.
> >
> > The problem is that SERIO==y means that SERIO_I8042 must be Y, as you
> > ran into. If you have SERIO only asked on EMBEDDED || !X86, and on
> > similar conditions you then select SERIO_I8042, it just works.
>
> No the problems occur when SERIO=m.
Ah, right, that got fixed for test4. Now I recall, I think.
> > > If SERIO is always y if !EMBEDDED || X86 my patch wouldn't be needed.
> >
> > Correct. I was suggesting that you do:
> > tristate "Serial i/o support (needed for keyboard and mouse)" if
> > !EMBEDDED || !X86 (or so)
> > select SERIO_I8042 if X86 && !EMBEDDED
> >
> > and then remove the conditions on SERIO_I8042, which puts all of the
> > auto-select-this magic in one spot.
>
> I can't see how this should work in all cases.
> Could you send how you'd like to formulate this?
This is done in the patch I sent to break EMBEDDED into STANDARD and
NONSTD_ABI. There it looks like (just the keyboard bits):
===== drivers/input/Kconfig 1.5 vs edited =====
--- 1.5/drivers/input/Kconfig Wed Jul 16 10:39:32 2003
+++ edited/drivers/input/Kconfig Fri Sep 5 14:45:36 2003
@@ -5,7 +5,9 @@
menu "Input device support"
config INPUT
- tristate "Input devices (needed for keyboard, mouse, ...)" if EMBEDDED
+ tristate "Input devices (needed for keyboard, mouse, ...)"
+ select INPUT_MOUSEDEV if STANDARD
+ select INPUT_KEYBOARD if STANDARD && X86
default y
---help---
Say Y here if you have any input device (mouse, keyboard, tablet,
[snip]
===== drivers/input/keyboard/Kconfig 1.6 vs edited =====
--- 1.6/drivers/input/keyboard/Kconfig Wed Jul 16 10:39:32 2003
+++ edited/drivers/input/keyboard/Kconfig Fri Sep 5 14:45:36 2003
@@ -2,8 +2,9 @@
# Input core configuration
#
config INPUT_KEYBOARD
- bool "Keyboards" if EMBEDDED || !X86
+ bool "Keyboards"
default y
+ select KEYBOARD_ATKBD if STANDARD && X86
depends on INPUT
help
Say Y here, and a list of supported keyboards will be displayed.
@@ -12,7 +13,7 @@
If unsure, say Y.
config KEYBOARD_ATKBD
- tristate "AT keyboard support" if EMBEDDED || !X86
+ tristate "AT keyboard support"
default y
depends on INPUT && INPUT_KEYBOARD && SERIO
help
===== drivers/input/serio/Kconfig 1.9 vs edited =====
--- 1.9/drivers/input/serio/Kconfig Wed Jul 16 10:39:32 2003
+++ edited/drivers/input/serio/Kconfig Fri Sep 5 14:45:36 2003
@@ -2,7 +2,8 @@
# Input core configuration
#
config SERIO
- tristate "Serial i/o support (needed for keyboard and mouse)"
+ tristate "Serial i/o support (needed for keyboard and mouse)" if !(STANDARD && X86)
+ select SERIO_I8042 if STANDARD && X86
default y
---help---
Say Yes here if you have any input device that uses serial I/O to
@@ -19,7 +20,7 @@
as a module, say M here and read <file:Documentation/modules.txt>.
config SERIO_I8042
- tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
+ tristate "i8042 PC Keyboard controller"
default y
depends on SERIO
---help---
Where STANDARD is normally Y and NONSTD_ABI is normally N. This groups
all of the "Well, we're standard so we want a keyboard" logic into 3
places. Really what could be done is in the question for STANDARD,
selecting all of the things at once. But I'm not sure if that really
helps or hurts, so I didn't do it.
--
Tom Rini
http://gate.crashing.org/~trini/
On Wed, Sep 10, 2003 at 12:31:58PM -0700, Tom Rini wrote:
>...
> ===== drivers/input/keyboard/Kconfig 1.6 vs edited =====
> --- 1.6/drivers/input/keyboard/Kconfig Wed Jul 16 10:39:32 2003
> +++ edited/drivers/input/keyboard/Kconfig Fri Sep 5 14:45:36 2003
> @@ -2,8 +2,9 @@
> # Input core configuration
> #
> config INPUT_KEYBOARD
> - bool "Keyboards" if EMBEDDED || !X86
> + bool "Keyboards"
> default y
> + select KEYBOARD_ATKBD if STANDARD && X86
> depends on INPUT
> help
> Say Y here, and a list of supported keyboards will be displayed.
> @@ -12,7 +13,7 @@
> If unsure, say Y.
>
> config KEYBOARD_ATKBD
> - tristate "AT keyboard support" if EMBEDDED || !X86
> + tristate "AT keyboard support"
> default y
> depends on INPUT && INPUT_KEYBOARD && SERIO
> help
> ===== drivers/input/serio/Kconfig 1.9 vs edited =====
> --- 1.9/drivers/input/serio/Kconfig Wed Jul 16 10:39:32 2003
> +++ edited/drivers/input/serio/Kconfig Fri Sep 5 14:45:36 2003
> @@ -2,7 +2,8 @@
> # Input core configuration
> #
> config SERIO
> - tristate "Serial i/o support (needed for keyboard and mouse)"
> + tristate "Serial i/o support (needed for keyboard and mouse)" if !(STANDARD && X86)
> + select SERIO_I8042 if STANDARD && X86
> default y
> ---help---
> Say Yes here if you have any input device that uses serial I/O to
This works but seems fragile since everyone touching the dependencies
must know that the tristate dependencies of SERIO must always match the
select dependencies in INPUT_KEYBOARD.
> @@ -19,7 +20,7 @@
> as a module, say M here and read <file:Documentation/modules.txt>.
>
> config SERIO_I8042
> - tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
> + tristate "i8042 PC Keyboard controller"
> default y
> depends on SERIO
> ---help---
>...
Yes, removing the "if EMBEDDED || !X86" solves the problem...
> Tom Rini
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Sep 10, 2003 at 09:55:44PM +0200, Adrian Bunk wrote:
> On Wed, Sep 10, 2003 at 12:31:58PM -0700, Tom Rini wrote:
> >...
> > ===== drivers/input/keyboard/Kconfig 1.6 vs edited =====
> > --- 1.6/drivers/input/keyboard/Kconfig Wed Jul 16 10:39:32 2003
> > +++ edited/drivers/input/keyboard/Kconfig Fri Sep 5 14:45:36 2003
> > @@ -2,8 +2,9 @@
> > # Input core configuration
> > #
> > config INPUT_KEYBOARD
> > - bool "Keyboards" if EMBEDDED || !X86
> > + bool "Keyboards"
> > default y
> > + select KEYBOARD_ATKBD if STANDARD && X86
> > depends on INPUT
> > help
> > Say Y here, and a list of supported keyboards will be displayed.
> > @@ -12,7 +13,7 @@
> > If unsure, say Y.
> >
> > config KEYBOARD_ATKBD
> > - tristate "AT keyboard support" if EMBEDDED || !X86
> > + tristate "AT keyboard support"
> > default y
> > depends on INPUT && INPUT_KEYBOARD && SERIO
> > help
> > ===== drivers/input/serio/Kconfig 1.9 vs edited =====
> > --- 1.9/drivers/input/serio/Kconfig Wed Jul 16 10:39:32 2003
> > +++ edited/drivers/input/serio/Kconfig Fri Sep 5 14:45:36 2003
> > @@ -2,7 +2,8 @@
> > # Input core configuration
> > #
> > config SERIO
> > - tristate "Serial i/o support (needed for keyboard and mouse)"
> > + tristate "Serial i/o support (needed for keyboard and mouse)" if !(STANDARD && X86)
> > + select SERIO_I8042 if STANDARD && X86
> > default y
> > ---help---
> > Say Yes here if you have any input device that uses serial I/O to
>
> This works but seems fragile since everyone touching the dependencies
> must know that the tristate dependencies of SERIO must always match the
> select dependencies in INPUT_KEYBOARD.
How so? SERIO only selects SERIO_* bits, and INPUT only selects INPUT*
(and, imho, keyboard is input :)) bits.
> > @@ -19,7 +20,7 @@
> > as a module, say M here and read <file:Documentation/modules.txt>.
> >
> > config SERIO_I8042
> > - tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
> > + tristate "i8042 PC Keyboard controller"
> > default y
> > depends on SERIO
> > ---help---
> >...
>
> Yes, removing the "if EMBEDDED || !X86" solves the problem...
Without other changes, it brings back the "user can shoot themselves in
the foot, easily." problem. You can only remove the 'if ...' if you
select it before.
--
Tom Rini
http://gate.crashing.org/~trini/
On Wed, Sep 10, 2003 at 02:04:43PM -0700, Tom Rini wrote:
> On Wed, Sep 10, 2003 at 09:55:44PM +0200, Adrian Bunk wrote:
> > On Wed, Sep 10, 2003 at 12:31:58PM -0700, Tom Rini wrote:
> > >...
> > > ===== drivers/input/keyboard/Kconfig 1.6 vs edited =====
> > > --- 1.6/drivers/input/keyboard/Kconfig Wed Jul 16 10:39:32 2003
> > > +++ edited/drivers/input/keyboard/Kconfig Fri Sep 5 14:45:36 2003
> > > @@ -2,8 +2,9 @@
> > > # Input core configuration
> > > #
> > > config INPUT_KEYBOARD
> > > - bool "Keyboards" if EMBEDDED || !X86
> > > + bool "Keyboards"
> > > default y
> > > + select KEYBOARD_ATKBD if STANDARD && X86
> > > depends on INPUT
> > > help
> > > Say Y here, and a list of supported keyboards will be displayed.
> > > @@ -12,7 +13,7 @@
> > > If unsure, say Y.
> > >
> > > config KEYBOARD_ATKBD
> > > - tristate "AT keyboard support" if EMBEDDED || !X86
> > > + tristate "AT keyboard support"
> > > default y
> > > depends on INPUT && INPUT_KEYBOARD && SERIO
> > > help
> > > ===== drivers/input/serio/Kconfig 1.9 vs edited =====
> > > --- 1.9/drivers/input/serio/Kconfig Wed Jul 16 10:39:32 2003
> > > +++ edited/drivers/input/serio/Kconfig Fri Sep 5 14:45:36 2003
> > > @@ -2,7 +2,8 @@
> > > # Input core configuration
> > > #
> > > config SERIO
> > > - tristate "Serial i/o support (needed for keyboard and mouse)"
> > > + tristate "Serial i/o support (needed for keyboard and mouse)" if !(STANDARD && X86)
> > > + select SERIO_I8042 if STANDARD && X86
> > > default y
> > > ---help---
> > > Say Yes here if you have any input device that uses serial I/O to
> >
> > This works but seems fragile since everyone touching the dependencies
> > must know that the tristate dependencies of SERIO must always match the
> > select dependencies in INPUT_KEYBOARD.
>
> How so? SERIO only selects SERIO_* bits, and INPUT only selects INPUT*
> (and, imho, keyboard is input :)) bits.
>...
Let's say you remove the X86 dependency in the select in INPUT_KEYBOARD.
If you select SERIO=m on !X86 (with EMBEDDED/STANDARD enabled) this will
select KEYBOARD_ATKBD=y...
> Tom Rini
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, Sep 11, 2003 at 12:17:11AM +0200, Adrian Bunk wrote:
> On Wed, Sep 10, 2003 at 03:05:52PM -0700, Tom Rini wrote:
> > > >
> > > > How so? SERIO only selects SERIO_* bits, and INPUT only selects INPUT*
> > > > (and, imho, keyboard is input :)) bits.
> > > >...
> > >
> > > Let's say you remove the X86 dependency in the select in INPUT_KEYBOARD.
> >
> > You mean:
> > select KEYBOARD_ATKBD if STANDARD && X86
> > becomes:
> > select KEYBOARD_ATKBD if STANDARD
> > ?
>
> Yes.
That would, well break things. We're only forcing ATKBD on X86 right
now, thankfully.
> > > If you select SERIO=m on !X86 (with EMBEDDED/STANDARD enabled) this will
> > > select KEYBOARD_ATKBD=y...
> >
> > How? What you pick for SERIO does not select anything in INPUT.
> >
> > select is 'stronger' than the {bool,tristate} "Foo" if ... usage, so if
> > you have broken dependancies you get a different kind of failure (link,
> > as opposed to a shot foot) but IMHO it's more correct for restraints
> > that are of the form:
> > "Don't let the user shoot themseleves in the foot, easily".
>
> There's a dependency between SERIO and KEYBOARD_ATKBD that must be
> represented in the config rules.
>
> Let me paraphrase the dependency the other way round (I'm not sure
> whether the syntax is 100% correct):
>
> config KEYBOARD_ATKBD
> tristate "AT keyboard support" if EMBEDDED || !X86
> default y
> depends on INPUT_KEYBOARD
> select SERIO=m
> select SERIO=y if KEYBOARD_ATKBD=y
> help
> ...
Ah yes.
This is similar (the same, even?) to the test3 problem. Roman, can we
get select to somehow pay attention to depend as well? I do believe
it's possible to have A select B, have C depend on Z and end up with:
A=y
B=y
C=n
--
Tom Rini
http://gate.crashing.org/~trini/
On Wed, Sep 10, 2003 at 03:05:52PM -0700, Tom Rini wrote:
> > >
> > > How so? SERIO only selects SERIO_* bits, and INPUT only selects INPUT*
> > > (and, imho, keyboard is input :)) bits.
> > >...
> >
> > Let's say you remove the X86 dependency in the select in INPUT_KEYBOARD.
>
> You mean:
> select KEYBOARD_ATKBD if STANDARD && X86
> becomes:
> select KEYBOARD_ATKBD if STANDARD
> ?
Yes.
> > If you select SERIO=m on !X86 (with EMBEDDED/STANDARD enabled) this will
> > select KEYBOARD_ATKBD=y...
>
> How? What you pick for SERIO does not select anything in INPUT.
>
> select is 'stronger' than the {bool,tristate} "Foo" if ... usage, so if
> you have broken dependancies you get a different kind of failure (link,
> as opposed to a shot foot) but IMHO it's more correct for restraints
> that are of the form:
> "Don't let the user shoot themseleves in the foot, easily".
There's a dependency between SERIO and KEYBOARD_ATKBD that must be
represented in the config rules.
Let me paraphrase the dependency the other way round (I'm not sure
whether the syntax is 100% correct):
config KEYBOARD_ATKBD
tristate "AT keyboard support" if EMBEDDED || !X86
default y
depends on INPUT_KEYBOARD
select SERIO=m
select SERIO=y if KEYBOARD_ATKBD=y
help
...
> Tom Rini
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Sep 10, 2003 at 11:51:37PM +0200, Adrian Bunk wrote:
> On Wed, Sep 10, 2003 at 02:04:43PM -0700, Tom Rini wrote:
> > On Wed, Sep 10, 2003 at 09:55:44PM +0200, Adrian Bunk wrote:
> > > On Wed, Sep 10, 2003 at 12:31:58PM -0700, Tom Rini wrote:
> > > >...
> > > > ===== drivers/input/keyboard/Kconfig 1.6 vs edited =====
> > > > --- 1.6/drivers/input/keyboard/Kconfig Wed Jul 16 10:39:32 2003
> > > > +++ edited/drivers/input/keyboard/Kconfig Fri Sep 5 14:45:36 2003
> > > > @@ -2,8 +2,9 @@
> > > > # Input core configuration
> > > > #
> > > > config INPUT_KEYBOARD
> > > > - bool "Keyboards" if EMBEDDED || !X86
> > > > + bool "Keyboards"
> > > > default y
> > > > + select KEYBOARD_ATKBD if STANDARD && X86
> > > > depends on INPUT
> > > > help
> > > > Say Y here, and a list of supported keyboards will be displayed.
> > > > @@ -12,7 +13,7 @@
> > > > If unsure, say Y.
> > > >
> > > > config KEYBOARD_ATKBD
> > > > - tristate "AT keyboard support" if EMBEDDED || !X86
> > > > + tristate "AT keyboard support"
> > > > default y
> > > > depends on INPUT && INPUT_KEYBOARD && SERIO
> > > > help
> > > > ===== drivers/input/serio/Kconfig 1.9 vs edited =====
> > > > --- 1.9/drivers/input/serio/Kconfig Wed Jul 16 10:39:32 2003
> > > > +++ edited/drivers/input/serio/Kconfig Fri Sep 5 14:45:36 2003
> > > > @@ -2,7 +2,8 @@
> > > > # Input core configuration
> > > > #
> > > > config SERIO
> > > > - tristate "Serial i/o support (needed for keyboard and mouse)"
> > > > + tristate "Serial i/o support (needed for keyboard and mouse)" if !(STANDARD && X86)
> > > > + select SERIO_I8042 if STANDARD && X86
> > > > default y
> > > > ---help---
> > > > Say Yes here if you have any input device that uses serial I/O to
> > >
> > > This works but seems fragile since everyone touching the dependencies
> > > must know that the tristate dependencies of SERIO must always match the
> > > select dependencies in INPUT_KEYBOARD.
> >
> > How so? SERIO only selects SERIO_* bits, and INPUT only selects INPUT*
> > (and, imho, keyboard is input :)) bits.
> >...
>
> Let's say you remove the X86 dependency in the select in INPUT_KEYBOARD.
You mean:
select KEYBOARD_ATKBD if STANDARD && X86
becomes:
select KEYBOARD_ATKBD if STANDARD
?
> If you select SERIO=m on !X86 (with EMBEDDED/STANDARD enabled) this will
> select KEYBOARD_ATKBD=y...
How? What you pick for SERIO does not select anything in INPUT.
select is 'stronger' than the {bool,tristate} "Foo" if ... usage, so if
you have broken dependancies you get a different kind of failure (link,
as opposed to a shot foot) but IMHO it's more correct for restraints
that are of the form:
"Don't let the user shoot themseleves in the foot, easily".
--
Tom Rini
http://gate.crashing.org/~trini/
Hi,
On Wed, 10 Sep 2003, Tom Rini wrote:
> > Let me paraphrase the dependency the other way round (I'm not sure
> > whether the syntax is 100% correct):
> >
> > config KEYBOARD_ATKBD
> > tristate "AT keyboard support" if EMBEDDED || !X86
> > default y
> > depends on INPUT_KEYBOARD
> > select SERIO=m
> > select SERIO=y if KEYBOARD_ATKBD=y
> > help
> > ...
>
> Ah yes.
>
> This is similar (the same, even?) to the test3 problem. Roman, can we
> get select to somehow pay attention to depend as well? I do believe
> it's possible to have A select B, have C depend on Z and end up with:
> A=y
> B=y
> C=n
Could you give me a complete example, I don't understand yet, what it's
exactly supposed to do.
bye, Roman
On Thu, Sep 11, 2003 at 10:38:58AM +0200, Roman Zippel wrote:
> Hi,
>
> On Wed, 10 Sep 2003, Tom Rini wrote:
>
> > > Let me paraphrase the dependency the other way round (I'm not sure
> > > whether the syntax is 100% correct):
> > >
> > > config KEYBOARD_ATKBD
> > > tristate "AT keyboard support" if EMBEDDED || !X86
> > > default y
> > > depends on INPUT_KEYBOARD
> > > select SERIO=m
> > > select SERIO=y if KEYBOARD_ATKBD=y
> > > help
> > > ...
> >
> > Ah yes.
> >
> > This is similar (the same, even?) to the test3 problem. Roman, can we
> > get select to somehow pay attention to depend as well? I do believe
> > it's possible to have A select B, have C depend on Z and end up with:
> > A=y
> > B=y
> > C=n
>
> Could you give me a complete example, I don't understand yet, what it's
> exactly supposed to do.
Okay. The following Kconfig illustrates what I claim to be a bug.
config A
bool "This is A"
select B
config B
bool "This is B"
# Or, depends C=y
depends C
config C
bool "This is C"
Running oldconfig will give:
This is A (A) [N/y] (NEW) y
This is C (C) [N/y] (NEW) n
...
And in .config:
CONFIG_A=y
CONFIG_B=y
# CONFIG_C is not set
I claim that this should in fact be:
CONFIG_A=y
CONFIG_B=y
CONFIG_C=y
--
Tom Rini
http://gate.crashing.org/~trini/
On Thu, Sep 11, 2003 at 04:04:48PM -0700, Tom Rini wrote:
>
> Okay. The following Kconfig illustrates what I claim to be a bug.
> config A
> bool "This is A"
> select B
>
> config B
> bool "This is B"
> # Or, depends C=y
> depends C
>
> config C
> bool "This is C"
>
>
> Running oldconfig will give:
> This is A (A) [N/y] (NEW) y
> This is C (C) [N/y] (NEW) n
> ...
> And in .config:
> CONFIG_A=y
> CONFIG_B=y
> # CONFIG_C is not set
>
> I claim that this should in fact be:
> CONFIG_A=y
> CONFIG_B=y
> CONFIG_C=y
The problem is that select ignores dependencies.
Unfortunately, your proposal wouldn't work easily, consider e.g.
config A
bool "This is A"
select B
config B
bool
depends C || D
config C
bool "This is C"
depends D=n
config D
bool "This is D"
Do you want C or D to be selected?
> Tom Rini
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, Sep 12, 2003 at 01:09:02PM +0200, Adrian Bunk wrote:
> On Thu, Sep 11, 2003 at 04:04:48PM -0700, Tom Rini wrote:
> >
> > Okay. The following Kconfig illustrates what I claim to be a bug.
> > config A
> > bool "This is A"
> > select B
> >
> > config B
> > bool "This is B"
> > # Or, depends C=y
> > depends C
> >
> > config C
> > bool "This is C"
> >
> >
> > Running oldconfig will give:
> > This is A (A) [N/y] (NEW) y
> > This is C (C) [N/y] (NEW) n
> > ...
> > And in .config:
> > CONFIG_A=y
> > CONFIG_B=y
> > # CONFIG_C is not set
> >
> > I claim that this should in fact be:
> > CONFIG_A=y
> > CONFIG_B=y
> > CONFIG_C=y
>
> The problem is that select ignores dependencies.
Yeap.
> Unfortunately, your proposal wouldn't work easily, consider e.g.
I'm not really claiming a proposal, just that if B needs C=y, then C
should C=y. I didn't say this would be an easy prolem, either :)
> config A
> bool "This is A"
> select B
>
> config B
> bool
> depends C || D
>
> config C
> bool "This is C"
> depends D=n
>
> config D
> bool "This is D"
>
>
> Do you want C or D to be selected?
With 'oldconfig' / 'config', you could loop until the user selects one
of them. Or, default to the first in the or series that can be
selected.
--
Tom Rini
http://gate.crashing.org/~trini/
On Fri, Sep 12, 2003 at 07:52:07AM -0700, Tom Rini wrote:
>...
> With 'oldconfig' / 'config', you could loop until the user selects one
> of them. Or, default to the first in the or series that can be
> selected.
What if all possible dependencies aren't available because their
dependencies aren't fulfilled?
I agree that there's a problem, but I think a good solution is
non-trivial.
> Tom Rini
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, Sep 12, 2003 at 05:04:49PM +0200, Adrian Bunk wrote:
> On Fri, Sep 12, 2003 at 07:52:07AM -0700, Tom Rini wrote:
> >...
> > With 'oldconfig' / 'config', you could loop until the user selects one
> > of them. Or, default to the first in the or series that can be
> > selected.
>
> What if all possible dependencies aren't available because their
> dependencies aren't fulfilled?
It's one of those recursive problems. But so long as we don't get
circular dependancies (which would be a bug anyhow, yes?) it should at
least be solvable.
>
> I agree that there's a problem, but I think a good solution is
> non-trivial.
Agreed.
--
Tom Rini
http://gate.crashing.org/~trini/
Hi,
On Fri, 12 Sep 2003, Adrian Bunk wrote:
> On Thu, Sep 11, 2003 at 04:04:48PM -0700, Tom Rini wrote:
> >
> > Okay. The following Kconfig illustrates what I claim to be a bug.
> > config A
> > bool "This is A"
> > select B
> >
> > config B
> > bool "This is B"
> > # Or, depends C=y
> > depends C
> >
> > config C
> > bool "This is C"
> >
> >
> > Running oldconfig will give:
> > This is A (A) [N/y] (NEW) y
> > This is C (C) [N/y] (NEW) n
> > ...
> > And in .config:
> > CONFIG_A=y
> > CONFIG_B=y
> > # CONFIG_C is not set
> >
> > I claim that this should in fact be:
> > CONFIG_A=y
> > CONFIG_B=y
> > CONFIG_C=y
>
> The problem is that select ignores dependencies.
>
>
> Unfortunately, your proposal wouldn't work easily,
Sometimes it's even impossible, e.g. if choice values are involved. It can
get even more complex, as a config symbol can be defined multiple times
and the dependencies belong to the prompt not to the symbol. Letting
select look at all the dependencies, would let the complexity explode.
Right now the simplest solution is to either let A select everything or B
uses select instead of depends.
bye, Roman
Although I can't keep up with the mailing list, I saw this from Adrian Bunk:
> On Thu, Sep 11, 2003 at 04:04:48PM -0700, Tom Rini wrote:
> >
> > Okay. The following Kconfig illustrates what I claim to be a bug.
> > config A
> > bool "This is A"
> > select B
> > config B
> > bool "This is B"
> > # Or, depends C=y
> > depends C
> > config C
> > bool "This is C"
> >
> > Running oldconfig will give:
> > This is A (A) [N/y] (NEW) y
> > This is C (C) [N/y] (NEW) n
> > And in .config:
> > CONFIG_A=y
> > CONFIG_B=y
> > # CONFIG_C is not set
This is a problem. Proposed solution follows later.
> > I claim that this should in fact be:
> > CONFIG_A=y
> > CONFIG_B=y
> > CONFIG_C=y
Even for this simple case, there are other possibilities. When we add human
logic to the specified sequence of events then we can say that your
interpretation is most likely what the user wanted, but in ordinary logic
there are other possibilities such as n, n, n. Proposed solution follows.
> The problem is that select ignores dependencies.
> Unfortunately, your proposal wouldn't work easily, consider e.g.
> config A
> bool "This is A"
> select B
> config B
> bool
> depends C || D
> config C
> bool "This is C"
> depends D=n
> config D
> bool "This is D"
> Do you want C or D to be selected?
If neither is selected, then the problem is essentially the same as the one
which Mr. Rini pointed out. And again there are other possible
possibilities such as n, n, n, n.
Solution: Surely plain "make" could start by checking dependencies. Or
maybe "make dep" could be reincarnated. If there is any inconsistency, then
the Makefile could issue an error and refuse to start compiling.
This has the added benefit that if the human has some reason to edit the
.config file by hand instead of using a make [...]config command, plain
"make" will have a chance of catching editing errors.
This doesn't automate a solution as thoroughly as either of you were hoping
for; it honestly admits that it can't read the human's mind :-)
On Sat, Sep 13, 2003 at 05:22:16PM +0900, Norman Diamond wrote:
> Although I can't keep up with the mailing list, I saw this from Adrian Bunk:
> > On Thu, Sep 11, 2003 at 04:04:48PM -0700, Tom Rini wrote:
> > >
> > > Okay. The following Kconfig illustrates what I claim to be a bug.
> > > config A
> > > bool "This is A"
> > > select B
> > > config B
> > > bool "This is B"
> > > # Or, depends C=y
> > > depends C
> > > config C
> > > bool "This is C"
> > >
> > > Running oldconfig will give:
> > > This is A (A) [N/y] (NEW) y
> > > This is C (C) [N/y] (NEW) n
> > > And in .config:
> > > CONFIG_A=y
> > > CONFIG_B=y
> > > # CONFIG_C is not set
>
> This is a problem. Proposed solution follows later.
>
> > > I claim that this should in fact be:
> > > CONFIG_A=y
> > > CONFIG_B=y
> > > CONFIG_C=y
>
> Even for this simple case, there are other possibilities. When we add human
> logic to the specified sequence of events then we can say that your
> interpretation is most likely what the user wanted, but in ordinary logic
> there are other possibilities such as n, n, n. Proposed solution follows.
>
> > The problem is that select ignores dependencies.
> > Unfortunately, your proposal wouldn't work easily, consider e.g.
> > config A
> > bool "This is A"
> > select B
> > config B
> > bool
> > depends C || D
> > config C
> > bool "This is C"
> > depends D=n
> > config D
> > bool "This is D"
> > Do you want C or D to be selected?
>
> If neither is selected, then the problem is essentially the same as the one
> which Mr. Rini pointed out. And again there are other possible
> possibilities such as n, n, n, n.
>
> Solution: Surely plain "make" could start by checking dependencies. Or
> maybe "make dep" could be reincarnated. If there is any inconsistency, then
> the Makefile could issue an error and refuse to start compiling.
>
> This has the added benefit that if the human has some reason to edit the
> .config file by hand instead of using a make [...]config command, plain
> "make" will have a chance of catching editing errors.
>
> This doesn't automate a solution as thoroughly as either of you were hoping
> for; it honestly admits that it can't read the human's mind :-)
Yes, even that would work quite nicely, perhaps while saying what the
specific problem is as well. Roman, how hard would this be to do?
--
Tom Rini
http://gate.crashing.org/~trini/
Hi,
On Mon, 15 Sep 2003, Tom Rini wrote:
> > If neither is selected, then the problem is essentially the same as the one
> > which Mr. Rini pointed out. And again there are other possible
> > possibilities such as n, n, n, n.
> >
> > Solution: Surely plain "make" could start by checking dependencies. Or
> > maybe "make dep" could be reincarnated. If there is any inconsistency, then
> > the Makefile could issue an error and refuse to start compiling.
> >
> > This has the added benefit that if the human has some reason to edit the
> > .config file by hand instead of using a make [...]config command, plain
> > "make" will have a chance of catching editing errors.
> >
> > This doesn't automate a solution as thoroughly as either of you were hoping
> > for; it honestly admits that it can't read the human's mind :-)
>
> Yes, even that would work quite nicely, perhaps while saying what the
> specific problem is as well. Roman, how hard would this be to do?
The check happens already and it will ask for any missing option.
You have to define what "inconsistency" means, right now the kconfig
design makes ambigous configurations impossible (provided that there are
no recursive dependencies, which kconfig warns about). I have no plans to
give up this property, as it keeps kconfig reasonably simple, it's already
complex enough as is.
bye, Roman
On Mon, Sep 15, 2003 at 11:06:06PM +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 15 Sep 2003, Tom Rini wrote:
>
> > > If neither is selected, then the problem is essentially the same as the one
> > > which Mr. Rini pointed out. And again there are other possible
> > > possibilities such as n, n, n, n.
> > >
> > > Solution: Surely plain "make" could start by checking dependencies. Or
> > > maybe "make dep" could be reincarnated. If there is any inconsistency, then
> > > the Makefile could issue an error and refuse to start compiling.
> > >
> > > This has the added benefit that if the human has some reason to edit the
> > > .config file by hand instead of using a make [...]config command, plain
> > > "make" will have a chance of catching editing errors.
> > >
> > > This doesn't automate a solution as thoroughly as either of you were hoping
> > > for; it honestly admits that it can't read the human's mind :-)
> >
> > Yes, even that would work quite nicely, perhaps while saying what the
> > specific problem is as well. Roman, how hard would this be to do?
>
> The check happens already and it will ask for any missing option.
> You have to define what "inconsistency" means, right now the kconfig
> design makes ambigous configurations impossible (provided that there are
> no recursive dependencies, which kconfig warns about). I have no plans to
> give up this property, as it keeps kconfig reasonably simple, it's already
> complex enough as is.
So long as it doesn't involve 'select', it won't let you be
inconsistent, yes. How exactly are items that come in from a select
evaluated right now?
--
Tom Rini
http://gate.crashing.org/~trini/
Hi,
On Mon, 15 Sep 2003, Tom Rini wrote:
> > You have to define what "inconsistency" means, right now the kconfig
> > design makes ambigous configurations impossible (provided that there are
> > no recursive dependencies, which kconfig warns about). I have no plans to
> > give up this property, as it keeps kconfig reasonably simple, it's already
> > complex enough as is.
>
> So long as it doesn't involve 'select', it won't let you be
> inconsistent, yes.
No, this is even true with the current select.
> How exactly are items that come in from a select
> evaluated right now?
'select' adds a reverse dependency to the selected option, e.g.
config FOO
select BAR if BAZ
BAR has now a reverse dependency of "FOO && BAZ" and the value of BAR is
calculated as "(user value && visibility) || reverse dependency"
(visibility is the dependencies of all BAR prompts). The details are in
symbol.c:sym_calc_value().
This allows to calculate the configuration in a single pass and as a side
effect avoids inconsistencies.
bye, Roman