Re: [patch] 2.6.0-test5: serio config broken?

Re: [patch] 2.6.0-test5: serio config broken?

[Norman Diamond]

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  :-)

Re: [patch] 2.6.0-test5: serio config broken?

[Tom Rini]

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/

Re: [patch] 2.6.0-test5: serio config broken?

[Roman Zippel]

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

Re: [patch] 2.6.0-test5: serio config broken?

[Tom Rini]

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/

Re: [patch] 2.6.0-test5: serio config broken?

[Roman Zippel]

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

Re: [patch] 2.6.0-test5: serio config broken?

[Roman Zippel]

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

Re: [patch] 2.6.0-test5: serio config broken?

[Tom Rini]

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/

Re: [patch] 2.6.0-test5: serio config broken?

[Adrian Bunk]

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

Re: [patch] 2.6.0-test5: serio config broken?

[Tom Rini]

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/

Re: [patch] 2.6.0-test5: serio config broken?

[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
> 
> 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

Re: [patch] 2.6.0-test5: serio config broken?

[Tom Rini]

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/

Re: [patch] 2.6.0-test5: serio config broken?

[Roman Zippel]

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

Re: [patch] 2.6.0-test5: serio config broken?

[Tom Rini]

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/

Re: [patch] 2.6.0-test5: serio config broken?

[Adrian Bunk]

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

Re: [patch] 2.6.0-test5: serio config broken?

[Tom Rini]

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/

Re: [patch] 2.6.0-test5: serio config broken?

[Adrian Bunk]

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

Re: [patch] 2.6.0-test5: serio config broken?

[Tom Rini]

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/

Re: [patch] 2.6.0-test5: serio config broken?

[Adrian Bunk]

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

Re: [patch] 2.6.0-test5: serio config broken?

[Tom Rini]

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/

Re: [patch] 2.6.0-test5: serio config broken?

[Adrian Bunk]

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

Re: [patch] 2.6.0-test5: serio config broken?

[Tom Rini]

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/

Re: [patch] 2.6.0-test5: serio config broken?

[Adrian Bunk]

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

Re: [patch] 2.6.0-test5: serio config broken?

[Tom Rini]

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/

Re: [patch] 2.6.0-test5: serio config broken?

[Adrian Bunk]

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

Re: [patch] 2.6.0-test5: serio config broken?

[Russell King]

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 (rmk@arm.linux.org.uk)	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

Re: [patch] 2.6.0-test5: serio config broken?

[Sytse Wielinga]

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...]

[patch] 2.6.0-test5: serio config broken?

[Adrian Bunk]

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