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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
