stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
end up with unbuildable configs.
Signed-off-by: Al Viro <[email protected]>
---
drivers/input/joystick/Kconfig | 1 +
drivers/input/misc/Kconfig | 5 +++++
drivers/input/mouse/Kconfig | 1 +
drivers/input/tablet/Kconfig | 4 ++++
drivers/input/touchscreen/Kconfig | 1 +
5 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index 82f563e..b002345 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -255,6 +255,7 @@ config JOYSTICK_JOYDUMP
config JOYSTICK_XPAD
tristate "X-Box gamepad support"
+ depends on USB_ARCH_HAS_HCD
select USB
help
Say Y here if you want to use the X-Box pad with your computer.
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 6013ace..842a7b4 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -84,6 +84,7 @@ config INPUT_ATLAS_BTNS
config INPUT_ATI_REMOTE
tristate "ATI / X10 USB RF remote control"
+ depends on USB_ARCH_HAS_HCD
select USB
help
Say Y here if you want to use an ATI or X10 "Lola" USB remote control.
@@ -99,6 +100,7 @@ config INPUT_ATI_REMOTE
config INPUT_ATI_REMOTE2
tristate "ATI / Philips USB RF remote control"
+ depends on USB_ARCH_HAS_HCD
select USB
help
Say Y here if you want to use an ATI or Philips USB RF remote control.
@@ -114,6 +116,7 @@ config INPUT_ATI_REMOTE2
config INPUT_KEYSPAN_REMOTE
tristate "Keyspan DMR USB remote control (EXPERIMENTAL)"
depends on EXPERIMENTAL
+ depends on USB_ARCH_HAS_HCD
select USB
help
Say Y here if you want to use a Keyspan DMR USB remote control.
@@ -128,6 +131,7 @@ config INPUT_KEYSPAN_REMOTE
config INPUT_POWERMATE
tristate "Griffin PowerMate and Contour Jog support"
+ depends on USB_ARCH_HAS_HCD
select USB
help
Say Y here if you want to use Griffin PowerMate or Contour Jog devices.
@@ -144,6 +148,7 @@ config INPUT_POWERMATE
config INPUT_YEALINK
tristate "Yealink usb-p1k voip phone"
depends EXPERIMENTAL
+ depends on USB_ARCH_HAS_HCD
select USB
help
Say Y here if you want to enable keyboard and LCD functions of the
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index 2ccc114..eb0167e 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -111,6 +111,7 @@ config MOUSE_SERIAL
config MOUSE_APPLETOUCH
tristate "Apple USB Touchpad support"
+ depends on USB_ARCH_HAS_HCD
select USB
help
Say Y here if you want to use an Apple USB Touchpad.
diff --git a/drivers/input/tablet/Kconfig b/drivers/input/tablet/Kconfig
index 12dfb0e..d371c0b 100644
--- a/drivers/input/tablet/Kconfig
+++ b/drivers/input/tablet/Kconfig
@@ -13,6 +13,7 @@ if INPUT_TABLET
config TABLET_USB_ACECAD
tristate "Acecad Flair tablet support (USB)"
+ depends on USB_ARCH_HAS_HCD
select USB
help
Say Y here if you want to use the USB version of the Acecad Flair
@@ -25,6 +26,7 @@ config TABLET_USB_ACECAD
config TABLET_USB_AIPTEK
tristate "Aiptek 6000U/8000U tablet support (USB)"
+ depends on USB_ARCH_HAS_HCD
select USB
help
Say Y here if you want to use the USB version of the Aiptek 6000U
@@ -49,6 +51,7 @@ config TABLET_USB_GTCO
config TABLET_USB_KBTAB
tristate "KB Gear JamStudio tablet support (USB)"
+ depends on USB_ARCH_HAS_HCD
select USB
help
Say Y here if you want to use the USB version of the KB Gear
@@ -61,6 +64,7 @@ config TABLET_USB_KBTAB
config TABLET_USB_WACOM
tristate "Wacom Intuos/Graphire tablet support (USB)"
+ depends on USB_ARCH_HAS_HCD
select USB
help
Say Y here if you want to use the USB version of the Wacom Intuos
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 5e640ae..4f09180 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -166,6 +166,7 @@ config TOUCHSCREEN_UCB1400
config TOUCHSCREEN_USB_COMPOSITE
tristate "USB Touchscreen Driver"
+ depends on USB_ARCH_HAS_HCD
select USB
help
USB Touchscreen driver for:
--
1.5.0-rc2.GIT
On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
>
> stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> end up with unbuildable configs.
BTW, this kind of situation happens often enough, so how about doing
the following: teach kconfig that if FOO selects BAR and BAR depends
on <expr>, we should act as if FOO had explicit depends on <expr>.
Rationale: if FOO selects BAR, BAR depends on <expr> and <expr> is false,
turning FOO on will land us into unbuildable configuration (BAR turned on,
dependencies of BAR are not satisfied). It really happens often enough to
be very annoying. And we have fsckloads of dependencies that are there
only because of such scenarios. Gets especially nasty when BAR is selected
by several dozens of options and dependencies of BAR change...
Implementing that is pretty simply; the only thing I'm not sure how to deal
with is how to show such inherited dependencies in menuconfig et.al.
Comments?
On Wed, 16 May 2007, Al Viro wrote:
>
> BTW, this kind of situation happens often enough, so how about doing
> the following: teach kconfig that if FOO selects BAR and BAR depends
> on <expr>, we should act as if FOO had explicit depends on <expr>.
Sounds sane. I wonder if there are any non-obvious gotchas, and I worry
that the indirect dependency ends up getting really confusing at times,
but I don't think the notion is broken - just worrying about how to *show*
this to explain what is going on when people say "why can't I select X".
Linus
On Wed, May 16, 2007 at 04:33:35AM +0100, Al Viro wrote:
> On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> >
> > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> > end up with unbuildable configs.
>
> BTW, this kind of situation happens often enough, so how about doing
> the following: teach kconfig that if FOO selects BAR and BAR depends
> on <expr>, we should act as if FOO had explicit depends on <expr>.
We first need to ensure that we don't have any cases which explore the
current behaviour. I wonder how the following will be interpreted with
the ARCH_IXP4XX=y and ARCH_IXP4XX=n cases:
arch/arm/common/Kconfig:config SA1111
arch/arm/common/Kconfig: bool
arch/arm/common/Kconfig: select DMABOUNCE
arch/arm/common/Kconfig:
arch/arm/common/Kconfig:config DMABOUNCE
arch/arm/common/Kconfig: bool
arch/arm/mach-ixp4xx/Kconfig:if ARCH_IXP4XX
arch/arm/mach-ixp4xx/Kconfig:
...
arch/arm/mach-ixp4xx/Kconfig:config DMABOUNCE
arch/arm/mach-ixp4xx/Kconfig- bool
arch/arm/mach-ixp4xx/Kconfig- default y
arch/arm/mach-ixp4xx/Kconfig- depends on PCI
...
arch/arm/mach-ixp4xx/Kconfig:endif
We also have:
arch/arm/mm/Kconfig:config CPU_32v6K
arch/arm/mm/Kconfig- bool "Support ARM V6K processor extensions" if !SMP
arch/arm/mm/Kconfig- depends on CPU_V6
arch/arm/mm/Kconfig- default y if SMP
which gives: option available on V6 CPUs, user selectable on V6 UP, always
selected on V6 SMP.
and:
arch/arm/mm/Kconfig:config CPU_V7
arch/arm/mm/Kconfig: bool "Support ARM V7 processor"
arch/arm/mm/Kconfig: depends on ARCH_INTEGRATOR
arch/arm/mm/Kconfig: select CPU_32v6K
It would be undesirable for CPU_V7 to depend on CPU_V6 being set. (V7
always has V6K.) I guess V6K would have to become:
config CPU_32v6K
bool "Support ARM V6K processor extensions" if !SMP && !CPU_V7
depends on CPU_V6 || CPU_V7
default y if SMP || CPU_V7
and the select statement removed from CPU_V7.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
Al Viro wrote:
>> stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
>> end up with unbuildable configs.
>
> BTW, this kind of situation happens often enough, so how about doing
> the following: teach kconfig that if FOO selects BAR and BAR depends
> on <expr>, we should act as if FOO had explicit depends on <expr>.
"A... select B" is just a flavor of "A... depends on B", with the
additional instruction to the Kconfig UIs: Don't hide A if you can
silently switch on B.
So, since it is just a flavor of 'depend on', it is very obvious that it
has to propagate indirect dependencies just like 'depends on' does.
[...]
> the only thing I'm not sure how to deal
> with is how to show such inherited dependencies in menuconfig et.al.
How about throwing "select" out of the Kconfig language and improving
the UIs instead, so that users find what they want and need?
Compare to software package management. I think most of the package
management systems store merely plain dependencies in the package
metadata. The package manager UIs then allow users to auto-select all
packages which package A depends on, show him what was selected, let him
edit his choice before massive downloads, et cetera. Also, package
manager UIs often offer some collections of typically used packages and
so on. I don't think the package metadata already contain some
instructions which stuff to pre-select for the user. It's all in the UIs.
Back to Kconfig.
We have
- driver-like options which enable building of certain functionality.
They often depend on multiple other options higher up, either by
directly depending on one other option which itself may depend on
others, or even by directly depending on several options (which each
may depend others.)
The driver-like options are the ones that are most relevant to users
because they ultimately decide what the kernel can do.
- Tunables which modify how those driver-like code will behave.
- Infrastructure (subsystem cores), libraries.
Nobody really cares about these on their own, we only want have all
those of them built which serve above mentioned driver-like options.
Did I forget anything?
So, we put
- metadata about kernel parts (what do they, what are their
dependencies)
into Kconfig files,
- methods to produce .configs (which honor the dependencies and
reflect which kernel functionality the user wanted)
into "make fooconfig" programs,
- user interfaces which control these methods
into "make fooconfig" programs.
The goal is to let the user safely and efficiently enable everything he
needs/ disable everything he doesn't need.
The question is: Which kind of information has to be put into the
Kconfig files to achieve this objective --- besides the plain
information about dependencies and human-readable information about the
functionality of the options?
Do we need instructions like "select" in Kconfig files, or do we rather
need more powerful "make fooconfig" programs?
PS: Actually, the problems with "select" which Al pointed out in the
parent post show that "select" doesn't really let us get by with less
powerful "make fooconfig" programs, because proper treatment of
"depends" is sometimes nontrivial.
PPS: Other current discussions indicate that additional metadata in the
Kconfigs might perhaps be useful, e.g. metadata about a kernel part's
lifecycle status (experimental, deprecated et al).
--
Stefan Richter
-=====-=-=== -=-= =----
http://arcgraph.de/sr/
On 5/16/07, Satyam Sharma <[email protected]> wrote:
> On 5/16/07, Al Viro <[email protected]> wrote:
> > On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> > >
> > > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> > > end up with unbuildable configs.
> >
> > BTW, this kind of situation happens often enough, so how about doing
> > the following: teach kconfig that if FOO selects BAR and BAR depends
> > on <expr>, we should act as if FOO had explicit depends on <expr>.
> >
> > Rationale: if FOO selects BAR, BAR depends on <expr> and <expr> is false,
> > turning FOO on will land us into unbuildable configuration (BAR turned on,
> > dependencies of BAR are not satisfied). It really happens often enough to
> > be very annoying. And we have fsckloads of dependencies that are there
> > only because of such scenarios. Gets especially nasty when BAR is selected
> > by several dozens of options and dependencies of BAR change...
>
> [ First off, "select"ing BAR that itself "depends on" BAZ is evil and
> should be avoided, except where BAR is strictly library-like and thus
> has simple or few basic dependencies. Still, like you say, dependencies
> of BAR can change over time, or one could want to be lazy and wish to
> avoid burdening users with having to pick dependencies _before_ the
> option they're interested in -- especially with menuconfig not even
> showing options whose dependencies are not satisfied already. ]
>
> Anyway, I'd gotten into a couple of threads discussing precisely this over
> the last couple of weeks, and thought of more-or-less a similar solution:
> http://lkml.org/lkml/2007/5/7/332
>
> When user picks FOO, we select BAR and note its dependencies (i.e. BAZ).
> Build a complete dependency tree (FOO upwards), and show to the user all
> the other config options (such as BAZ) that will now have to be picked
> to satisfy user's selection of FOO without causing build breakages. If
> user says yes, we *select* BAZ too (so now it can't be un-selected). If
> user says no, FOO is not picked at all.
>
> On 5/16/07, Al Viro <[email protected]> wrote:
> > Implementing that is pretty simply; the only thing I'm not sure how to deal
> > with is how to show such inherited dependencies in menuconfig et.al.
>
> On 5/16/07, Linus Torvalds <[email protected]> wrote:
> > Sounds sane. I wonder if there are any non-obvious gotchas, and I worry
> > that the indirect dependency ends up getting really confusing at times,
> > but I don't think the notion is broken - just worrying about how to *show*
> > this to explain what is going on when people say "why can't I select X".
>
> For menuconfig / xconfig it _could_ simply be another dialog box that
> pops up the moment user picks FOO.
>
> For config/oldconfig/etc non-curses/graphics-based ones, we could do
> something like what "yum" does for package dependencies on Red Hat
> and Fedora. Once the entire thing is done, just run through the entire
> .config just generated, and build these complete dependency trees for
> all picked options, and thus compiling a list of all the BAZ'es that also
> need to be picked now to satisfy user's demand for the FOO's.
> Simple Y/n then follows.
One minor glitch here: BAZ may not be a "select"able dependency at all.
Like Al wrote, it could be an <expr> that is something like !SMP etc that
can't be meaningfully selected.
For that case, menuconfig / xconfig could simply show up a dialog
explaining why the user's selection of FOO can't be allowed, and
config/oldconfig/etc can simply refuse to write out the broken .config.
On 5/16/07, Al Viro <[email protected]> wrote:
> On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> >
> > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> > end up with unbuildable configs.
>
> BTW, this kind of situation happens often enough, so how about doing
> the following: teach kconfig that if FOO selects BAR and BAR depends
> on <expr>, we should act as if FOO had explicit depends on <expr>.
>
> Rationale: if FOO selects BAR, BAR depends on <expr> and <expr> is false,
> turning FOO on will land us into unbuildable configuration (BAR turned on,
> dependencies of BAR are not satisfied). It really happens often enough to
> be very annoying. And we have fsckloads of dependencies that are there
> only because of such scenarios. Gets especially nasty when BAR is selected
> by several dozens of options and dependencies of BAR change...
[ First off, "select"ing BAR that itself "depends on" BAZ is evil and
should be avoided, except where BAR is strictly library-like and thus
has simple or few basic dependencies. Still, like you say, dependencies
of BAR can change over time, or one could want to be lazy and wish to
avoid burdening users with having to pick dependencies _before_ the
option they're interested in -- especially with menuconfig not even
showing options whose dependencies are not satisfied already. ]
Anyway, I'd gotten into a couple of threads discussing precisely this over
the last couple of weeks, and thought of more-or-less a similar solution:
http://lkml.org/lkml/2007/5/7/332
When user picks FOO, we select BAR and note its dependencies (i.e. BAZ).
Build a complete dependency tree (FOO upwards), and show to the user all
the other config options (such as BAZ) that will now have to be picked
to satisfy user's selection of FOO without causing build breakages. If
user says yes, we *select* BAZ too (so now it can't be un-selected). If
user says no, FOO is not picked at all.
On 5/16/07, Al Viro <[email protected]> wrote:
> Implementing that is pretty simply; the only thing I'm not sure how to deal
> with is how to show such inherited dependencies in menuconfig et.al.
On 5/16/07, Linus Torvalds <[email protected]> wrote:
> Sounds sane. I wonder if there are any non-obvious gotchas, and I worry
> that the indirect dependency ends up getting really confusing at times,
> but I don't think the notion is broken - just worrying about how to *show*
> this to explain what is going on when people say "why can't I select X".
For menuconfig / xconfig it _could_ simply be another dialog box that
pops up the moment user picks FOO.
For config/oldconfig/etc non-curses/graphics-based ones, we could do
something like what "yum" does for package dependencies on Red Hat
and Fedora. Once the entire thing is done, just run through the entire
.config just generated, and build these complete dependency trees for
all picked options, and thus compiling a list of all the BAZ'es that also
need to be picked now to satisfy user's demand for the FOO's.
Simple Y/n then follows.
Satyam
Stefan Richter wrote:
> "A... select B" is just a flavor of "A... depends on B", with the
> additional instruction to the Kconfig UIs: Don't hide A if you can
> silently switch on B.
I think you mean "A... select B" is just a flavor of "B... depends on A". There is one
minor difference between the two.
If A is a driver and B is a library, then it's more intuitive to update the Kconfig option
for A then it is to update the Kconfig option for B. For example, if I want to add a new
driver C that uses library B, I can just add this:
C
select B
If I have to use "depends on", then I would have to change the Kconfig option for B like this:
B
depends on A || C
And every time I create a new driver that depends on library B, I have to update that
"depends on" line *in addition to* creating the Kconfig line for the new driver. If 10
drivers use library B, you'll have this:
B
depends on A || C || D || E || F || G || H || I || J || K
> How about throwing "select" out of the Kconfig language and improving
> the UIs instead, so that users find what they want and need?
I know a lot of people don't like 'select', but I prefer it over 'depends on'.
--
Timur Tabi
Linux Kernel Developer @ Freescale
Timur Tabi wrote:
> Stefan Richter wrote:
>> "A... select B" is just a flavor of "A... depends on B",
...
> I think you mean "A... select B" is just a flavor of "B... depends on
> A".
No, A requires B's symbols.
--
Stefan Richter
-=====-=-=== -=-= =---=
http://arcgraph.de/sr/
Timur Tabi wrote:
> For example, if I want to add a new driver C that uses library B, I can
> just add this:
>
> C
> select B
>
> If I have to use "depends on", then I would have to change the Kconfig
> option for B like this:
>
> B
> depends on A || C
You mean, "B... serves A, C".
However, it shouldn't matter which way around the dependencies are
written down in the Kconfigs. What does matter is how "make
{old,menu,...}config" deal with it.
--
Stefan Richter
-=====-=-=== -=-= =---=
http://arcgraph.de/sr/
Hi,
On Wed, 16 May 2007, Al Viro wrote:
> On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> >
> > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> > end up with unbuildable configs.
>
> BTW, this kind of situation happens often enough, so how about doing
> the following: teach kconfig that if FOO selects BAR and BAR depends
> on <expr>, we should act as if FOO had explicit depends on <expr>.
select was really intended to override the dependencies (Russell gave a
few examples), the other usage is what is abusing select (I can
understand why people are doing it, but it still is).
So I'd really like to get the focus away from select and rather see it as
a new syntax.
One problem with your idea is that a symbol itself has no normal
dependencies. A symbol has properties and these have the dependencies, so
it's not that easy. What could be used is the visibility value of a symbol
of a symbol, but that can't be used in expressions yet.
The problem is now being able to select visible and nonvisible symbols.
One way is to introduce a new syntax for the behaviour you suggest or we
change the current select syntax and mark nonvisible symbols as being
selectable. Considering the current problems I sort of like the latter.
bye, Roman