LinuxLists.cc - Super Kernel Sunday!

[permalink] [raw]

Subject: [patch] MTD: fix DOC2000/2001/2001PLUS build error

* Linus Torvalds <[email protected]> wrote:

> The half-time entertainment is provided by randomly inserted trivial
> syntax errors that nerds are expected to fix at home before completing
> the compile, but most people actually seem to mostly enjoy watching
> the compile warnings, sponsored by Anheuser-Busch, scroll past.

i am honored to present the very first build fix for v2.6.20, as a
tribute to the Colts.

Ingo

-------------------->
Subject: [patch] MTD: fix DOC2000/2001/2001PLUS build error
From: Ingo Molnar <[email protected]>

The very first "make ARCH=i386 randconfig" gave this build error:

LD vmlinux
drivers/built-in.o: In function `cafe_nand_remove':
cafe.c:(.text+0x19277a): undefined reference to `nand_release'
drivers/built-in.o: In function `cafe_nand_cmdfunc':
cafe.c:(.text+0x193036): undefined reference to `nand_wait_ready'
drivers/built-in.o: In function `cafe_nand_probe':
cafe.c:(.text+0x19359e): undefined reference to `nand_scan_ident'
cafe.c:(.text+0x193658): undefined reference to `nand_scan_tail'
distcc[1703] ERROR: compile (null) on localhost failed
make: *** [vmlinux] Error 1

which i suspect was a side-effect of the late and optimistic MTD merge.

but hey, we always knew Linux was better at offense than at defense, and
good offense is what wins the game in the end, as the Bears had to find
out the hard way ;-)

so here's the fix for the 3 affected MTD drivers: DOC2000, DOC2001 and
DOC2001PLUS.

Signed-off-by: Ingo Molnar <[email protected]>
---
drivers/mtd/devices/Kconfig | 3 +++
1 file changed, 3 insertions(+)

Index: linux/drivers/mtd/devices/Kconfig
===================================================================
--- linux.orig/drivers/mtd/devices/Kconfig
+++ linux/drivers/mtd/devices/Kconfig
@@ -152,6 +152,7 @@ config MTD_DOC2000
tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)"
depends on MTD
select MTD_DOCPROBE
+ select MTD_NAND
select MTD_NAND_IDS
---help---
This provides an MTD device driver for the M-Systems DiskOnChip
@@ -175,6 +176,7 @@ config MTD_DOC2001
tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)"
depends on MTD
select MTD_DOCPROBE
+ select MTD_NAND
select MTD_NAND_IDS
---help---
This provides an alternative MTD device driver for the M-Systems
@@ -197,6 +199,7 @@ config MTD_DOC2001PLUS
tristate "M-Systems Disk-On-Chip Millennium Plus"
depends on MTD
select MTD_DOCPROBE
+ select MTD_NAND
select MTD_NAND_IDS
---help---
This provides an MTD device driver for the M-Systems DiskOnChip

2007-02-05 13:06:21

by Josh Boyer

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On 2/5/07, Ingo Molnar <[email protected]> wrote:
> Subject: [patch] MTD: fix DOC2000/2001/2001PLUS build error
> From: Ingo Molnar <[email protected]>
>
> The very first "make ARCH=i386 randconfig" gave this build error:
>
> LD vmlinux
> drivers/built-in.o: In function `cafe_nand_remove':
> cafe.c:(.text+0x19277a): undefined reference to `nand_release'
> drivers/built-in.o: In function `cafe_nand_cmdfunc':
> cafe.c:(.text+0x193036): undefined reference to `nand_wait_ready'
> drivers/built-in.o: In function `cafe_nand_probe':
> cafe.c:(.text+0x19359e): undefined reference to `nand_scan_ident'
> cafe.c:(.text+0x193658): undefined reference to `nand_scan_tail'
> distcc[1703] ERROR: compile (null) on localhost failed
> make: *** [vmlinux] Error 1
>
> which i suspect was a side-effect of the late and optimistic MTD merge.
>
> but hey, we always knew Linux was better at offense than at defense, and
> good offense is what wins the game in the end, as the Bears had to find
> out the hard way ;-)
>
> so here's the fix for the 3 affected MTD drivers: DOC2000, DOC2001 and
> DOC2001PLUS.

Erm... from your output above, cafe.c is completely separate from the
DOC drivers. Does this also need a fix, or...

David?

josh

2007-02-05 13:34:57

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 2007-02-05 at 09:45 +0100, Ingo Molnar wrote:
> LD vmlinux
> drivers/built-in.o: In function `cafe_nand_remove':
> cafe.c:(.text+0x19277a): undefined reference to `nand_release'
> drivers/built-in.o: In function `cafe_nand_cmdfunc':
> cafe.c:(.text+0x193036): undefined reference to `nand_wait_ready'
> drivers/built-in.o: In function `cafe_nand_probe':
> cafe.c:(.text+0x19359e): undefined reference to `nand_scan_ident'
> cafe.c:(.text+0x193658): undefined reference to `nand_scan_tail'
> distcc[1703] ERROR: compile (null) on localhost failed
> make: *** [vmlinux] Error 1

> so here's the fix for the 3 affected MTD drivers: DOC2000, DOC2001 and
> DOC2001PLUS.

Er, what?

For a start, the affected driver is the new CAFÉ NAND controller, not
the old versions of the DiskOnChip drivers which don't even use the
generic NAND code anyway.

Secondly, please don't _ever_ use 'select'. If ESR's Aunt Tillie
_really_ needs to configure a new kernel for her $100 laptop, but she
lacks the wit to realise that she might need to ask for NAND flash
support if she wants to be able to enable the NAND flash controller,
then I really couldn't care less.

We now have a fairly arbitrary mix of 'select' and proper dependencies
throughout the kernel, and it's getting harder and harder to configure a
minimal kernel by turning off subsystems we don't want, because
something 'helpfully' turns then back on again.

We could do with some coherent guidelines on _when_ to use 'select' and
when to use normal dependencies. Personally, I'm quite happy to tell
Aunt Tillie to go screw herself and for that guidance to be to _never_
use 'select'.

The correct fix is at
http://git.infradead.org/?p=mtd-2.6.git;a=commitdiff;h=aa8f1278553c554f1fb3fd6fb0987dd547c7d7cf;hp=4285431fb658263e98942ce2320b0b26eddcc06d

--
dwmw2

2007-02-05 16:00:20

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

* David Woodhouse <[email protected]> wrote:

> On Mon, 2007-02-05 at 09:45 +0100, Ingo Molnar wrote:
> > LD vmlinux
> > drivers/built-in.o: In function `cafe_nand_remove':
> > cafe.c:(.text+0x19277a): undefined reference to `nand_release'
> > drivers/built-in.o: In function `cafe_nand_cmdfunc':
> > cafe.c:(.text+0x193036): undefined reference to `nand_wait_ready'
> > drivers/built-in.o: In function `cafe_nand_probe':
> > cafe.c:(.text+0x19359e): undefined reference to `nand_scan_ident'
> > cafe.c:(.text+0x193658): undefined reference to `nand_scan_tail'
> > distcc[1703] ERROR: compile (null) on localhost failed
> > make: *** [vmlinux] Error 1
>
> > so here's the fix for the 3 affected MTD drivers: DOC2000, DOC2001 and
> > DOC2001PLUS.
>
> Er, what?
>
> For a start, the affected driver is the new CAF? NAND controller, not
> the old versions of the DiskOnChip drivers which don't even use the
> generic NAND code anyway.
>
> Secondly, please don't _ever_ use 'select'. [...]

i only did the simple & minimal thing and extended the already existing
select code that was there:

tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)"
depends on MTD
select MTD_DOCPROBE
+ select MTD_NAND
select MTD_NAND_IDS
---help---

feel free to get rid of the original selects there.

> [...] If ESR's Aunt Tillie _really_ needs to configure a new kernel
> for her $100 laptop, but she lacks the wit to realise that she might
> need to ask for NAND flash support if she wants to be able to enable
> the NAND flash controller, then I really couldn't care less.

i agree and i disagree. I agree that sprinkling tons of selects all
around the Kconfigs would be bad - a dependency should only be expressed
once.

But i disagree with your notion that it's somehow wrong to be able to
select a component somewhere which then picks its dependencies. I think
the right solution is not to be ambivalent towards the needs of aunts,
but to extend the Kconfig language (and/or tools surrounding it) to be
able to activate an inactive config entry by automatically selecting all
its required dependencies. (just like package managers can do it on any
modern distro)

Furthermore, there's a solution already within the existing Kconfig
language: the Kconfig hierarchy should be a tree alike hiearachy of
dependencies, /not/ a generic, messy directed graph. In terms of Kconfig
dependencies: if you need the NAND subsystem for certain types of
drivers then do it like networking: collect those dependent drivers
under CONFIG_NET_PCI, and make that whole category dependent on
CONFIG_PCI. Not like the MTD code does it today: there's a
"Self-contained MTD device drivers" category and a separate selectable
CONFIG_MTD_NAND and there's a magic non-tree dependency between them.

btw., this whole select problem is not limited to Aunt Tillie: in a
couple of cases in the past few months when i saw some weird code in a
driver and tried to enable it i had to search around for many minutes
and enable random options to figure out its config dependencies until i
had the driver truly enabled. (if there's some easy solution to this
then i'm all ears - but i exclude the easiest solution of adding me to
the 'aunt' category ;-) I think that by blaming Aunt Tillie you might be
missing the real problem.

Ingo

2007-02-05 16:08:13

by Arjan van de Ven

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 2007-02-05 at 16:56 +0100, Ingo Molnar wrote:
>
> btw., this whole select problem is not limited to Aunt Tillie: in a
> couple of cases in the past few months when i saw some weird code in
> a
> driver and tried to enable it i had to search around for many minutes
> and enable random options to figure out its config dependencies until
> i
> had the driver truly enabled. (if there's some easy solution to this
> then i'm all ears - but i exclude the easiest solution of adding me
> to
> the 'aunt' category ;-) I think that by blaming Aunt Tillie you might
> be
> missing the real problem.

the real problem is that we plain have way too many config options ;)
While it's nice to make some things conditional, I have the feeling that
things have gone too far in the kernel today....

--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

2007-02-05 16:12:47

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, Feb 05, 2007 at 04:56:27PM +0100, Ingo Molnar wrote:
> btw., this whole select problem is not limited to Aunt Tillie: in a
> couple of cases in the past few months when i saw some weird code in a
> driver and tried to enable it i had to search around for many minutes
> and enable random options to figure out its config dependencies until i
> had the driver truly enabled. (if there's some easy solution to this
> then i'm all ears - but i exclude the easiest solution of adding me to
> the 'aunt' category ;-) I think that by blaming Aunt Tillie you might be
> missing the real problem.

Adding a 'select' statement might solve that particular problem:

"What config symbols do I need to turn on to enable FOO"

but it creates another problem which is at precisely the same level.
IOW:

"What config symbols do I need to turn off to disable FOO"

Both require the use of grep to solve it. Both are as bad as each
other. 'select' only moves the problem - it doesn't actually solve
anything.

The real problem is that "band-aiding" the problem is all too easy,
so we just bung a select in. We're actually storing up bigger problems
for the future, making the kernel configuration system more and more
complex, sometimes creating circular dependencies through select/depends,
basically turning it into something several orders of magnitude worse
than the original shell scripts.

The only real way I see the problem truely getting solved is if folk
start standing up against throwing "select" in so there's some
motivation to actually fix the underlying problem.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:

2007-02-05 16:21:50

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

* Russell King <[email protected]> wrote:

> On Mon, Feb 05, 2007 at 04:56:27PM +0100, Ingo Molnar wrote:
> > btw., this whole select problem is not limited to Aunt Tillie: in a
> > couple of cases in the past few months when i saw some weird code in a
> > driver and tried to enable it i had to search around for many minutes
> > and enable random options to figure out its config dependencies until i
> > had the driver truly enabled. (if there's some easy solution to this
> > then i'm all ears - but i exclude the easiest solution of adding me to
> > the 'aunt' category ;-) I think that by blaming Aunt Tillie you might be
> > missing the real problem.
>
> Adding a 'select' statement might solve that particular problem:
>
> "What config symbols do I need to turn on to enable FOO"
>
> but it creates another problem which is at precisely the same level.
> IOW:
>
> "What config symbols do I need to turn off to disable FOO"
>
> Both require the use of grep to solve it. Both are as bad as each
> other. 'select' only moves the problem - it doesn't actually solve
> anything.

yes, in the example above i only outlined that the problem is real and
not limited to Aunt Tillie's.

> The real problem is that "band-aiding" the problem is all too easy, so
> we just bung a select in. We're actually storing up bigger problems
> for the future, making the kernel configuration system more and more
> complex, sometimes creating circular dependencies through
> select/depends, basically turning it into something several orders of
> magnitude worse than the original shell scripts.

circular dependencies are nicely detected, warned about and worked
around by the Kconfig system. I fixed one such bug recently. I have to
say the Kconfig code has improved very significantly during the past few
years and i dont want any of what i'm writing to be understood as a
criticism. It's more in the direction of: 'ok, things are pretty nice
and the config tree works currently, now lets make it even cleaner'.

> The only real way I see the problem truely getting solved is if folk
> start standing up against throwing "select" in so there's some
> motivation to actually fix the underlying problem.

the solution is i think two-fold and goes along the lines i outlined in
the previous mail:

- make dependencies as tree-alike as possible

note that the MTD problem was caused by those drivers not being part of
a clean tree.

But even with a 100% clean tree structure there's a legitimate desire to
select modules several layers down from the current 'leaf' nodes of the
config tree:

- provide a tool mode (not a Kconfig language feature) to navigate the
complete tree of features (including currently disabled ones) and
enable the selection of components (by automatically selecting all
dependent features).

Ingo

2007-02-05 16:22:26

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 2007-02-05 at 16:56 +0100, Ingo Molnar wrote:
> i only did the simple & minimal thing and extended the already existing
> select code that was there:
>
> tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)"
> depends on MTD
> select MTD_DOCPROBE
> + select MTD_NAND
> select MTD_NAND_IDS
> ---help---
>
> feel free to get rid of the original selects there.

Those are different, because they select items which are not
user-visible. It's just a trick to avoid having the same thing
implemented in the Makefiles like it used to be. We used to have stuff
like...
obj-$(CONFIG_MTD_NAND) += nand-ids.o
obj-$(CONFIG_MTD_DOC2000) += nand-ids.o
... but now we have those options select MTD_NAND_IDS instead. That's a
reasonable enough use of select. I really don't see any reason for using
it for items which _are_ visible to the user though.

> > [...] If ESR's Aunt Tillie _really_ needs to configure a new kernel
> > for her $100 laptop, but she lacks the wit to realise that she might
> > need to ask for NAND flash support if she wants to be able to enable
> > the NAND flash controller, then I really couldn't care less.
>
> i agree and i disagree. I agree that sprinkling tons of selects all
> around the Kconfigs would be bad - a dependency should only be expressed
> once.

We _are_ sprinkling tons of selects all around the Kconfigs. And we're
doing it inconsistently -- nobody seems to agree on when to use 'select'
and when to use proper dependencies.

I think that "only use select for non-user-visible options" is a
perfectly good rule.

> But i disagree with your notion that it's somehow wrong to be able to
> select a component somewhere which then picks its dependencies. I think
> the right solution is not to be ambivalent towards the needs of aunts,
> but to extend the Kconfig language (and/or tools surrounding it) to be
> able to activate an inactive config entry by automatically selecting all
> its required dependencies. (just like package managers can do it on any
> modern distro)

It's something we can do in the tools -- if you want to turn an option
on, you can see what its dependencies are and turn them all on in one
go. In fact that's something which was implemented in external variants
of the tcl-based xconfig as long ago as 1997. I think our new xconfig
implementation now does it too.

> Furthermore, there's a solution already within the existing Kconfig
> language: the Kconfig hierarchy should be a tree alike hiearachy of
> dependencies, /not/ a generic, messy directed graph. In terms of Kconfig
> dependencies: if you need the NAND subsystem for certain types of
> drivers then do it like networking: collect those dependent drivers
> under CONFIG_NET_PCI, and make that whole category dependent on
> CONFIG_PCI. Not like the MTD code does it today: there's a
> "Self-contained MTD device drivers" category and a separate selectable
> CONFIG_MTD_NAND and there's a magic non-tree dependency between them.

No, it was MTD_NAND_CAFE which requires MTD_NAND, and that _is_ within
the same tree. I don't know why you added it to the old monolithic
DiskOnChip driver.

> btw., this whole select problem is not limited to Aunt Tillie: in a
> couple of cases in the past few months when i saw some weird code in a
> driver and tried to enable it i had to search around for many minutes
> and enable random options to figure out its config dependencies until i
> had the driver truly enabled. (if there's some easy solution to this
> then i'm all ears - but i exclude the easiest solution of adding me to
> the 'aunt' category ;-)

I come across this frequently -- and I just look at the Kconfig file to
see the dependencies of the option I want to enable. It's usually very
simple.

It's got a _lot_ harder recently to turn stuff _off_, as rmk observes.
You don't just look at the option you're interested in; you have to grep
all over the rest of the tree to find the 'select' which is forcing it
on after you turn it off. It's no longer in one place.

> I think that by blaming Aunt Tillie you might be
> missing the real problem.

No, by arbitrarily throwing 'select' into the mix with no real guidance
as to when to use it and when to use normal dependencies, _that's_ when
we're missing the real problem.

--
dwmw2

2007-02-05 16:30:42

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

* David Woodhouse <[email protected]> wrote:

> No, it was MTD_NAND_CAFE which requires MTD_NAND, and that _is_ within
> the same tree. I don't know why you added it to the old monolithic
> DiskOnChip driver.

yeah, i mis-analyzed the point of breakage - and my Kconfig hack simply
papered it over by accident. I agree that your fix is the right one.

> > btw., this whole select problem is not limited to Aunt Tillie: in a
> > couple of cases in the past few months when i saw some weird code in
> > a driver and tried to enable it i had to search around for many
> > minutes and enable random options to figure out its config
> > dependencies until i had the driver truly enabled. (if there's some
> > easy solution to this then i'm all ears - but i exclude the easiest
> > solution of adding me to the 'aunt' category ;-)
>
> I come across this frequently -- and I just look at the Kconfig file
> to see the dependencies of the option I want to enable. It's usually
> very simple.

i come across this problem frequently, and sometimes it's far from
simple and involves half a dozen Kconfigs. For example pick up a Fedora
.config of your choice and disable CONFIG_I2C.

> It's got a _lot_ harder recently to turn stuff _off_, as rmk observes.
> You don't just look at the option you're interested in; you have to
> grep all over the rest of the tree to find the 'select' which is
> forcing it on after you turn it off. It's no longer in one place.

yeah.

> > I think that by blaming Aunt Tillie you might be missing the real
> > problem.
>
> No, by arbitrarily throwing 'select' into the mix with no real
> guidance as to when to use it and when to use normal dependencies,
> _that's_ when we're missing the real problem.

we should not have 'select' at all - unless it's some non-code option
that is just a convenience switch for several other config options. A
true dependency is already expressed in one direction via the 'depend
on' directive - no need to express it in the other direction as well,
that only leads to redundancy and to bugs.

Ingo

2007-02-05 16:33:20

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 5 Feb 2007, David Woodhouse wrote:
>
> Secondly, please don't _ever_ use 'select'.

No, David.

I don't know why you keep repeating this mantra, when it's WRONG.

Using "select" is a lot more sane and intelligent than assuming that users
know what dependencies they want.

The Kconfig files should ask about *end-user* visible features. They
should say "do you want to support X".

If "X" then needs Y, Z and something else to actually compile, then that
Kconfig file should DAMN WELL use "select". Stop claiming anything else!

The user shouldn't know that they should say that they need some library Y
in order to even see the question for "X". It's not a sane thing to ask
them to know and care about. They care about the devices or capabilities
they want to support, not about the fact that a USB storage device needs
the SCSI core layer, for example.

So stop saying "don't use select".

Linus

2007-02-05 16:33:58

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 2007-02-05 at 17:26 +0100, Ingo Molnar wrote:
> > I come across this frequently -- and I just look at the Kconfig file
> > to see the dependencies of the option I want to enable. It's usually
> > very simple.
>
> i come across this problem frequently, and sometimes it's far from
> simple and involves half a dozen Kconfigs. For example pick up a Fedora
> .config of your choice and disable CONFIG_I2C.

Erm, isn't that _my_ example? I'm willing to bet that it'll take me
hours to turn _off_ CONFIG_I2C because the widespread abuse of 'select'
helpfully turning it back on again for me because I have some video
stuff, or some thermal stuff, etc.

> > It's got a _lot_ harder recently to turn stuff _off_, as rmk observes.
> > You don't just look at the option you're interested in; you have to
> > grep all over the rest of the tree to find the 'select' which is
> > forcing it on after you turn it off. It's no longer in one place.
>
> yeah.
>
> > > I think that by blaming Aunt Tillie you might be missing the real
> > > problem.
> >
> > No, by arbitrarily throwing 'select' into the mix with no real
> > guidance as to when to use it and when to use normal dependencies,
> > _that's_ when we're missing the real problem.
>
> we should not have 'select' at all - unless it's some non-code option
> that is just a convenience switch for several other config options. A
> true dependency is already expressed in one direction via the 'depend
> on' directive - no need to express it in the other direction as well,
> that only leads to redundancy and to bugs.

Right.

--
dwmw2

2007-02-05 16:35:31

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

* Ingo Molnar <[email protected]> wrote:

> we should not have 'select' at all - unless it's some non-code option
> that is just a convenience switch for several other config options. A
> true dependency is already expressed in one direction via the 'depend
> on' directive - no need to express it in the other direction as well,
> that only leads to redundancy and to bugs.

but this is /only/ practical if all (even disabled) features are visible
(and selectable) in the tools. They are not at the moment, so selects
are quite useful.

Ingo

2007-02-05 16:46:23

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, Feb 05, 2007 at 05:26:35PM +0100, Ingo Molnar wrote:
> we should not have 'select' at all - unless it's some non-code option
> that is just a convenience switch for several other config options. A
> true dependency is already expressed in one direction via the 'depend
> on' directive - no need to express it in the other direction as well,
> that only leads to redundancy and to bugs.

I disagree. There's a valid use for select.

config PCI
bool "PCI support" if ARCH_INTEGRATOR_AP || ARCH_VERSATILE_PB || ARCH_IXP4XX
default y if ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX || \
ARCH_IXP2000 || ARCH_IXP23XX || ARCH_SHARK || \
ARCH_CATS || ARCH_PERSONAL_SERVER || ARCH_EBSA285_HOST || \
ARCH_NETWINDER || MACH_NSLU2 || MACH_AVILA || \
ARCH_ADI_COYOTE || MACH_NAS100D || MACH_GTWX5715
depends on ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX || \
ARCH_IXP2000 || ARCH_IXP23XX || ARCH_SHARK || \
ARCH_CATS || ARCH_PERSONAL_SERVER || ARCH_EBSA285_HOST || \
ARCH_NETWINDER || MACH_NSLU2 || MACH_AVILA || \
ARCH_ADI_COYOTE || MACH_NAS100D || MACH_GTWX5715 || \
ARCH_INTEGRATOR_AP || ARCH_VERSATILE_PB || ARCH_IXP4XX

where (ARCH_INTEGRATOR_AP || ARCH_VERSATILE_PB || ARCH_IXP4XX) can not be
are mutually exclusive with the remaining group

vs:

config PCI
bool "PCI support" if ARCH_INTEGRATOR_AP || ARCH_VERSATILE_PB || ARCH_IXP4XX

and the rest (ie, except integrator, versatile and ixp4xx) has:

config ARCH_SHARK
bool "Shark"
select PCI

IOW, the "PCI support" question isn't offered for platforms which require
PCI to be present, but is offered on platforms where it's optional.

To you, which looks more maintainable?

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:

2007-02-05 16:51:04

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, Feb 05, 2007 at 08:32:50AM -0800, Linus Torvalds wrote:
> If "X" then needs Y, Z and something else to actually compile, then that
> Kconfig file should DAMN WELL use "select". Stop claiming anything else!

Disagree. The UI app should handle this and ask the user if it's okay
to proceed to enable that option along with the others.

All we should be doing in the Kconfig files is describing the
dependencies for user-visible symbols. If we want to allow the
user to enable something, it's up to the UI _itself_ to sort out the
dependencies.

Principle of least surprise. Principle of giving the user control.

As I say at the moment throwing "select" is just moving the bloody
problem around. It's not actually _solving_ anything, and anyone
who thinks otherwise is a nutcase!

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:

2007-02-05 16:52:29

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 2007-02-05 at 08:32 -0800, Linus Torvalds wrote:
>
> On Mon, 5 Feb 2007, David Woodhouse wrote:
> >
> > Secondly, please don't _ever_ use 'select'.
>
> No, David.
>
> I don't know why you keep repeating this mantra, when it's WRONG.

It may not shock you to find that I repeat it because I disagree.

> Using "select" is a lot more sane and intelligent than assuming that users
> know what dependencies they want.
>
> The Kconfig files should ask about *end-user* visible features. They
> should say "do you want to support X".

For the benefit of some, that's useful. Others still want to be able to
turn off entire subsystems when they don't compile or when they want to
quickly build a minimal kernel. It's become very hard to do that though.

> If "X" then needs Y, Z and something else to actually compile, then that
> Kconfig file should DAMN WELL use "select". Stop claiming anything else!

I agree that the tools should let them do that easily. It doesn't
necessarily follow that we should use 'select' for that purpose.

> The user shouldn't know that they should say that they need some library Y
> in order to even see the question for "X". It's not a sane thing to ask
> them to know and care about. They care about the devices or capabilities
> they want to support, not about the fact that a USB storage device needs
> the SCSI core layer, for example.

This I agree with. And it's something which the _tools_ have been
capable of for a long time. You don't need 'select'.

The problem is that the widespread and inconsistent use of 'select' for
Aunt Tillie's benefit causes problems for a _different_ set of people.
To use Ingo's example -- if I want to turn off CONFIG_I2C because it
doesn't build or I want it modular to hack on it, I want to be able to
just _do_ that.

I don't want to find that it's forced to 'Y' because I also happen to be
building support for some esoteric peripheral that I've never heard of.
I want that that peripheral to be turned _off_ when I turn I2C off. I
don't want to have to spend hours grepping _all_ over the tree to find
out what's forcing I2C on again. When it was just dependencies, it was
easy enough to find -- it was right there in the Kconfig file in one
place. Now it's a lot harder.

And I'm sure you aren't seriously suggesting that we should take it all
the way and that, for example, all SCSI host drivers should 'select
SCSI' rather than merely depending on SCSI? If I configure a kernel I
don't _want_ to be asked individually about every leaf option -- I want
to be able to turn stuff off in an orderly fashion; in a tree as Ingo
suggests.

--
dwmw2

2007-02-05 16:56:27

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

* Russell King <[email protected]> wrote:

> and the rest (ie, except integrator, versatile and ixp4xx) has:
>
> config ARCH_SHARK
> bool "Shark"
> select PCI
>
> IOW, the "PCI support" question isn't offered for platforms which
> require PCI to be present, but is offered on platforms where it's
> optional.

yeah. I think this also fits into the special-case i mentioned: it isnt
connected to something user-selectable, it's a side-effect of the first
'feature selection' the user does: 'what platform do you compile your
kernel on'. As such it is a convenience group-selection.

i.e. what we have behind this is still a clean tree of dependencies.

The mess begins i think when options with real code behind them start to
grow back and forth dependencies in form of criss-crossing 'depends on'
and 'select' instances.

Ingo

2007-02-05 16:58:44

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 5 Feb 2007, Ingo Molnar wrote:
>
> but this is /only/ practical if all (even disabled) features are visible
> (and selectable) in the tools. They are not at the moment, so selects
> are quite useful.

More importantly, some things that *are* visible probably shouldn't be, or
should perhaps only be in expert mode (aka "EMBEDDED").

A prime example of this is all the firewall settings. I'd personally
prefer to just select a "default firewall setup" which would be enough
for all the normal crud, instead of seeing 50 different choices.

And dammit, I'm supposed to be "technical". So if _I_ find it irritating
to have to select all those NF_MATCH_xxx/NF_TARGET_xxx crud things,
imagine what most people must feel like?

Me, I'd like to say I want "default firewall built in", and not have to
see *any* of the crap. And that's exactly why "select" is a good thing.

Not using select, and have people having to say "y" to the basic feature
and then y/m/n to each sub-feature is really damn annoying.

So thank God for the few selects we have, and we should add a whole lot
more!

Linus

2007-02-05 17:04:25

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, Feb 05, 2007 at 05:52:33PM +0100, Ingo Molnar wrote:
>
> * Russell King <[email protected]> wrote:
>
> > and the rest (ie, except integrator, versatile and ixp4xx) has:
> >
> > config ARCH_SHARK
> > bool "Shark"
> > select PCI
> >
> > IOW, the "PCI support" question isn't offered for platforms which
> > require PCI to be present, but is offered on platforms where it's
> > optional.
>
> yeah. I think this also fits into the special-case i mentioned: it isnt
> connected to something user-selectable, it's a side-effect of the first
> 'feature selection' the user does: 'what platform do you compile your
> kernel on'. As such it is a convenience group-selection.
>
> i.e. what we have behind this is still a clean tree of dependencies.

I agree 100% with that - since when that happens it's possible to
traverse the tree to tell the user what's going on.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:

2007-02-05 17:08:52

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, Feb 05, 2007 at 08:58:10AM -0800, Linus Torvalds wrote:
> On Mon, 5 Feb 2007, Ingo Molnar wrote:
> >
> > but this is /only/ practical if all (even disabled) features are visible
> > (and selectable) in the tools. They are not at the moment, so selects
> > are quite useful.
>
> More importantly, some things that *are* visible probably shouldn't be, or
> should perhaps only be in expert mode (aka "EMBEDDED").
>
> A prime example of this is all the firewall settings. I'd personally
> prefer to just select a "default firewall setup" which would be enough
> for all the normal crud, instead of seeing 50 different choices.

That also falls within my rule of "user visible symbols should not be
selected".

But... we already do something like this already and it doesn't take
a scattering of "select" to achieve. Look at fs/partitions/Kconfig
as a good example.

You get offered "Advanced partition support" as the first question.
If you say "N", you get something reasonable for your platform. If
you say "Y" you're free to choose whatever silly combination you
want, but with reasonable defaults offered.

That's something that a sprinking of select just can't do.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:

2007-02-05 17:09:10

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

* Linus Torvalds <[email protected]> wrote:

> Me, I'd like to say I want "default firewall built in", and not have
> to see *any* of the crap. And that's exactly why "select" is a good
> thing.

yeah. For a long time i wanted to do something like that for all the
kernel debugging options, to by default only offer a simple menu of:

( ) Debug Disabled
(*) Transparent Low-Overhead Debugging
( ) Transparent Medium-Overhead Debugging
( ) Transparent High-Overhead Debugging
( ) Custom Debugging

so say softlockup-detect or spinlock-sleep checks would be enabled by
Low-Overhead Debugging, but slab-debug or lockdep would only be enabled
by the High-Overhead Debugging option.

and all the zillions of debug options would only show up if "Custom
Debugging" is selected. Plus this would have the advantage that if we
add a new debug option, and the tester already has a .config with say
"Transparent Low-Overhead Debugging" enabled - Kconfig would pick the
right value for that new debug option. This would remove the need and
desire to 'default y' certain debugging features to get them tested ...

Ingo

2007-02-05 17:59:01

by Jan Engelhardt

[permalink] [raw]

Subject: Re: Super Kernel Sunday!

Hi,

>VERSION = 2
>PATCHLEVEL = 6
>SUBLEVEL = 20
>EXTRAVERSION =
>NAME = Homicidal Dwarf Hamster

Bah! And I had expected "Super Sunday Kernel" here. :>

BTW: is @osdl.org still valid?

Jan
--
ft: http://freshmeat.net/p/chaostables/

2007-02-05 19:07:43

by Kevin Fox

[permalink] [raw]

Subject: Re: Super Kernel Sunday!

Somehow, this image seems appropriate to go along with the release
name...

http://homepage.mac.com/whymme/WFRP/misc/warhamster/warhamster.html

On Mon, 2007-02-05 at 18:58 +0100, Jan Engelhardt wrote:
> Hi,
>
>
> >VERSION = 2
> >PATCHLEVEL = 6
> >SUBLEVEL = 20
> >EXTRAVERSION =
> >NAME = Homicidal Dwarf Hamster
>
> Bah! And I had expected "Super Sunday Kernel" here. :>
>
> BTW: is @osdl.org still valid?
>
>
> Jan

2007-02-05 21:15:11

by Ingo Oeser

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Monday, 5. February 2007, Linus Torvalds wrote:
> So thank God for the few selects we have, and we should add a whole lot
> more!

But "select" is not fine grained enough.

I would like to have "require", "recommend", "suggest" for feature A.

require X
does not work without X, but X is way down the tree
e.g. ext3 and block device or how select currently is intended

recommend X
it is usable but uncomfortable without X, enabled per default
e.g. firewalling recommends connection tracking support
or NAT recommends all NAT helpers

suggest X
many people use A together with X,
so you might be interested in enabling it, but I disabled it
per default unless you said "featuritis mode" before.
e.g. highmem and SMP or a network driver and NAPI.

That is what the Debian/Ubuntu package management does and maybe other too.
And this also gives us new keywords to replace select with,
so migration is doable :-)

This would also make "EMBEDDED" superflous, because it would just mean
"disable anything not required".

And this would enable an individual tree for the users current configuration
problem instead of a global one.

Regards

Ingo "and tomorrow we change the world" Oeser :-)

2007-02-05 21:18:11

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 2007-02-05 at 08:58 -0800, Linus Torvalds wrote:
> More importantly, some things that *are* visible probably shouldn't be, or
> should perhaps only be in expert mode (aka "EMBEDDED").

I've heard some fairly stupid abuse of the term 'embedded' in my time,
but rarely have I heard people daft enough to abuse it to mean 'expert'.
But yes, that's what we use CONFIG_EMBEDDED for.

> A prime example of this is all the firewall settings. I'd personally
> prefer to just select a "default firewall setup" which would be enough
> for all the normal crud, instead of seeing 50 different choices.

No, that's a really poor example. That's not what 'select' is for. We
can handle that kind of thing perfectly well without select -- just with
sensible _defaults_, much as we do for block device partitions and a few
other things.

> Me, I'd like to say I want "default firewall built in", and not have to
> see *any* of the crap. And that's exactly why "select" is a good thing.
>
> Not using select, and have people having to say "y" to the basic feature
> and then y/m/n to each sub-feature is really damn annoying.

No, you're thinking of something else. The use of 'select' just turns
the problem backwards -- if _every_ SCSI hostadapter were to 'select
SCSI' instead of depending on it, then I'd have to say 'n' to every damn
one of them instead of being able to just say 'n' to SCSI as I can at
the moment.

Well, I say 'just turns it backwards', but in fact it also makes it much
worse, because it's now much _harder_ to turn SCSI off, because there
might be random stuff else elsewhere in the tree which selects it rather
than having all the dependencies right on the option I'm interested in,
where I can see them and turn them on/off as required.

The dependency thing for Aunt Tillie is easily fixed in the tools, and
the firewall example you're thinking of is _far_ from being an example
of why 'select' is useful.

--
dwmw2

2007-02-05 21:29:21

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 5 Feb 2007, David Woodhouse wrote:
>
> No, you're thinking of something else. The use of 'select' just turns
> the problem backwards -- if _every_ SCSI hostadapter were to 'select
> SCSI' instead of depending on it, then I'd have to say 'n' to every damn
> one of them instead of being able to just say 'n' to SCSI as I can at
> the moment.

Right. Because for MOST scsi drivers, it's obvious that they are SCSI to
the user.

So we ask "do you want SCSI" in order to not ask a million questions that
a lot of people know a-priori that they don't want.

But if you cannot see that this is something TOTALLY DIFFERENT from USB
storage, you're either being obtuse on purpose, or just incapable of
understanding humans.

We should NEVER have had "USB_STORAGE" depending on SCSI. It'sa BUG. It's
a _stupid_ bug.

We should have done what is sane:
- make CONFIG_SCSI (as a "support the SCSI layer" be invisible to users,
because it's not a user decision.
- have a CONFIG_SCSI_DRIVER question for "do you want to be asked about
SCSI drivers" (and which also does "select SCSI" for you)
- make USB_STORAGE _also_ do the "select SCSI" thing.

In other words, you seem to be totally unable to grasp my argument. You
are arguing on TOTALLY IRRELEVANT TECHNICAL GROUNDS. That's not what the
Kconfig language is about. The Kconfig language and rules are about HUMAN
interaction.

So next time you say something about Kconfig, ask yourself: "What question
would a user want to see".

Any other question is pretty much totally irrelevant, and your "don't use
select" rule comes from your confusion that thinks that it's somehow about
machines and technical issues. It's not.

Linus

2007-02-05 21:37:47

by Alan

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

> No, you're thinking of something else. The use of 'select' just turns
> the problem backwards -- if _every_ SCSI hostadapter were to 'select
> SCSI' instead of depending on it, then I'd have to say 'n' to every damn
> one of them instead of being able to just say 'n' to SCSI as I can at
> the moment.

Tools issue. You want a "really de-select right now" button

Alan

2007-02-05 21:40:12

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 2007-02-05 at 13:28 -0800, Linus Torvalds wrote:
> Right. Because for MOST scsi drivers, it's obvious that they are SCSI to
> the user.

Really? Including the 'Scanner driver' card which arrived with my
scanner?

Is that like the 'RAID' card which is obviously RAID to the user, and
not at all IDE?

> But if you cannot see that this is something TOTALLY DIFFERENT from USB
> storage, you're either being obtuse on purpose, or just incapable of
> understanding humans.
>
> We should NEVER have had "USB_STORAGE" depending on SCSI. It'sa BUG. It's
> a _stupid_ bug.
>
> We should have done what is sane:
> - make CONFIG_SCSI (as a "support the SCSI layer" be invisible to users,
> because it's not a user decision.
> - have a CONFIG_SCSI_DRIVER question for "do you want to be asked about
> SCSI drivers" (and which also does "select SCSI" for you)
> - make USB_STORAGE _also_ do the "select SCSI" thing.

Crap. What we should have done is fix the tools so that when you go to
enable USB_STORAGE, it either prompts you or automatically turns on
SCSI. I saw versions of our tcl xconfig a _decade_ ago which were
capable of this, but we never cared enough to merge it -- although I
_thought_ our new xconfig could do it these days.

> In other words, you seem to be totally unable to grasp my argument. You
> are arguing on TOTALLY IRRELEVANT TECHNICAL GROUNDS. That's not what the
> Kconfig language is about. The Kconfig language and rules are about HUMAN
> interaction.

Well that's a shame, because any sane person would realise that most
humans interact with kernel configuration only through a distribution.

> So next time you say something about Kconfig, ask yourself: "What question
> would a user want to see".
>
> Any other question is pretty much totally irrelevant, and your "don't use
> select" rule comes from your confusion that thinks that it's somehow about
> machines and technical issues. It's not.

No, really. Eric's Aunt Tillie can go screw herself backwards with a
chainsaw. I care about _my_ use of configuration, and mostly my
requirement is that I want to turn something _off_ either because it
doesn't work, or I want it modular so I can hack on it, or because I'm
trying to cut down kernel size and I don't want it.

The proliferation of 'select' has made that a _complete_ pain in the
wossname, apparently for the benefit of some hypothetical relative of a
gun nut, who doesn't actually care because in general she doesn't
configure her own kernel anyway.

Russell is right -- using 'select' just turns the problem backwards,
pessimising it for the _common_ case.

--
dwmw2

2007-02-05 21:41:25

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 2007-02-05 at 21:50 +0000, Alan wrote:
> > No, you're thinking of something else. The use of 'select' just turns
> > the problem backwards -- if _every_ SCSI hostadapter were to 'select
> > SCSI' instead of depending on it, then I'd have to say 'n' to every damn
> > one of them instead of being able to just say 'n' to SCSI as I can at
> > the moment.
>
> Tools issue. You want a "really de-select right now" button

That's a useful suggestion actually -- one answer to this bogus
proliferation of 'select' is to hack the tools so that they treat
occurrences of 'select' referring to a _visible_ option as the
dependencies which they _should_ have been, rather than this silly new
behaviour.

--
dwmw2

2007-02-05 21:49:57

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 5 Feb 2007, David Woodhouse wrote:

> On Mon, 2007-02-05 at 13:28 -0800, Linus Torvalds wrote:
> > Right. Because for MOST scsi drivers, it's obvious that they are SCSI to
> > the user.
>
> Really? Including the 'Scanner driver' card which arrived with my
> scanner?

Can you read? Can you UNDERSTAND?

This is exactly my point.

If it's not obviously a SCSI card, then it shouldn't be "depends on SCSI".
It should be on its own and "select SCSI".

The whole AND ALMOST ONLY point of "depends on" is really to allow people
to do a shorthand or know that "ok, he gave us some information that makes
this choice pointless".

And yes, we've messed that up. But you're apparently arguing that the
mess-up is something "good".

"select" is _good_. Because it's the thing that avoids us having to ask
totally inane questions THAT DO NOT MAKE SENSE to a user.

It's totally idiotic that we should ask people for SCSI support. That's
not a user question, unless we're talking "odd-ball obviously SCSI
devices", and then the question actually makes sense as a way to allow 99%
of all users to say "nope" and not have to see another million questions
that aren't relevant to them.

Linus

2007-02-05 21:53:28

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 2007-02-05 at 13:49 -0800, Linus Torvalds wrote:
> Can you read? Can you UNDERSTAND?
>
> This is exactly my point.
>
> If it's not obviously a SCSI card, then it shouldn't be "depends on SCSI".
> It should be on its own and "select SCSI".
>
> The whole AND ALMOST ONLY point of "depends on" is really to allow people
> to do a shorthand or know that "ok, he gave us some information that makes
> this choice pointless".

You're asking _me_ if I can read?

Ten years ago, people used 'depends on' to fix the tools, so that then
you want to enable something like USB_STORAGE, it can automatically turn
SCSI on for you.

Isn't that what you wanted?

You don't need to screw over the technical users -- the _common_ case --
in order to achieve that.

We had it. TEN YEARS AGO. In the tools.

--
dwmw2

2007-02-05 22:08:32

by Alan

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

> > Really? Including the 'Scanner driver' card which arrived with my
> > scanner?
>
> Can you read? Can you UNDERSTAND?
>
> This is exactly my point.
>
> If it's not obviously a SCSI card, then it shouldn't be "depends on SCSI".
> It should be on its own and "select SCSI".

It works both ways. If I don't need to know that I must select SCSI then
it turns on easily. If I want to turn SCSI off then it causes mayhem. Two
sides of the same coin.

What is missing from the current config tools is that when you try and
turn SCSI off you can't. If there is a "really turn it off" button, then
you get told

Disabling SCSI will disable
USB scanner
Foo
Bar

Disable Y/N

it fixes Dave's problem.

There are great examples of this - trying to kill off the I2C bus in a
small build is one of the most painful. Yes users shouldn't need to know
to turn it on, but it does need a way to turn it back off sanely.

Alan

2007-02-05 22:22:06

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 5 Feb 2007, David Woodhouse wrote:
>
> Ten years ago, people used 'depends on' to fix the tools, so that then
> you want to enable something like USB_STORAGE, it can automatically turn
> SCSI on for you.
>
> Isn't that what you wanted?

Try it. It's not what it does.

If you have a

depends on SCSI

and you did not say you wanted SCSI, you'll never even *see* the question.

It will *not* turn on SCSI automatically for you. Quite the reverse. It
will not even show you the option.

In contrast, it you do a

select SCSI

you'll see the question, and it will do exactly what you claim "depends
on" does. Which yes, is what we want.

So what's your problem? You argue as if you didn't understand the
difference between "depends on" and "select".

As an example of this, look at SATA. It does "select SCSI" if you select
CONFIG_ATA, _exactly_ because it actually wants to turn on the SCSI layer
*regardless* of what the user said. Because if the user said "n" to SCSI,
the user simply didn't know that the SATA code uses the SCSI code.

Which is an example of what I've been saying all along: "select" makes
sense. USB_STORAGE should have done the same.

Claiming that "select" is evil is just totally strange.

Linus

2007-02-05 22:25:14

by Thomas Bächler

[permalink] [raw]

Subject: [2.6.20] Regression in dmfe driver

Commit 7628b0a8c01a02966d2228bdf741ddedb128e8f8 (drivers/net/tulip/dmfe:
support basic carrier detection) breaks networking on my Davicom DM9009.
ethtool always reports there is no link. tcpdump shows incoming packets,
but TX is disabled. Reverting the above patch fixes the problem.

2007-02-05 22:35:15

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 5 Feb 2007, Alan wrote:
>
> It works both ways. If I don't need to know that I must select SCSI then
> it turns on easily. If I want to turn SCSI off then it causes mayhem. Two
> sides of the same coin.

They are not really symmetric, though.

There's two big issues:

- tuning things "on" is more likely to cause a working kernel.

This is pretty fundamental. It's almost always simply more correct to
add features than remove them. At worst, it won't be used.

This argues that you should have to "work less" to turn something on,
and in particular, you should need to _know_ less. To turn something
off, you not only need to know how to turn it off, you fundamentally
need to know something much bigger: you need to know that you
really don't need it in the first place.

The interaction of CONFIG_ATA/CONFIG_SCSI is an example of the latter.
You really *do* need to know more to turn off SCSI - because you need
to know that the ATA layer depends on it.

So in the absense of knowledge, turning things on is better.

- A developer who really wants to turn things off, and knows enough that
that is actually safe, can really just do a "grep" for it. If you're
_extremely_ knowledgeable, you can do something like

git grep 'select.*\<SCSI\>' -- '*onfig*'

and that easily finds you the (currently single) place that turns on
SCSI (and yes, you can try it with I2C too, and try to recursively
figure out what it is that turns on I2C even though you *tried* to turn
it off. I2C - the option that just wouldn't die! ;)

So I agree that they are two facets of the same coin, but I claim that
there's a huge reason why they are not mirror-images - there are often
reasons to prefer one over the other.

That said: I really don't think "depends on" should just always be
"select" either. There's a balance:

- you use "depends on" when you can ask a simple question like "what kind
of machine do you have" or "do you want to support USB" or "do you have
SCSI devices".

But even then, you might end up having some devices that are
*technically* USB, but people don't think of them that way (for
example, some laptop add-ons are literally USB devices that are "built
into" the laptop - you might well decide to show those choices even if
somebody said "no USB", and if he then says "yeah, I have one of those
things", you just know he wasn't clueful enough, and you enable USB
behind his back _anyway_. Exact same thing as with SATA support)

- you use "select" when the question more naturally went the other way
(because the infrastructure isn't obvious)

So they are two similar things, and which one to choose mainly depends on
how you want to phrase the question - not on technical issues per se.

So neither is "wrong". They both have their downsides.

Linus

2007-02-05 22:37:01

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 5 Feb 2007 14:21:41 -0800 (PST) Linus Torvalds wrote:

> On Mon, 5 Feb 2007, David Woodhouse wrote:
> >
> > Ten years ago, people used 'depends on' to fix the tools, so that then
> > you want to enable something like USB_STORAGE, it can automatically turn
> > SCSI on for you.
> >
> > Isn't that what you wanted?
>
> Try it. It's not what it does.
>
> If you have a
>
> depends on SCSI
>
> and you did not say you wanted SCSI, you'll never even *see* the question.
>
> It will *not* turn on SCSI automatically for you. Quite the reverse. It
> will not even show you the option.
>
> In contrast, it you do a
>
> select SCSI
>
> you'll see the question, and it will do exactly what you claim "depends
> on" does. Which yes, is what we want.
>
> So what's your problem? You argue as if you didn't understand the
> difference between "depends on" and "select".

I think the problem is "who is make *config" for?".

David wants it to be for developers (ISTM) and "select" is a
hassle for us.

Linus wants it to be for (unadvanced) users, but they tend to just
use distro kernels and distro configs, according to David, and I
agree with that.

So I think that make *config is more for developers and advanced
(not embedded) users.

> As an example of this, look at SATA. It does "select SCSI" if you select
> CONFIG_ATA, _exactly_ because it actually wants to turn on the SCSI layer
> *regardless* of what the user said. Because if the user said "n" to SCSI,
> the user simply didn't know that the SATA code uses the SCSI code.
>
> Which is an example of what I've been saying all along: "select" makes
> sense. USB_STORAGE should have done the same.
>
> Claiming that "select" is evil is just totally strange.

It's a real problem for developers who actually try to modify
configs.

---
~Randy

2007-02-05 23:09:36

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 5 Feb 2007, Randy Dunlap wrote:
>
> I think the problem is "who is make *config" for?".

Absolutely.

> Linus wants it to be for (unadvanced) users, but they tend to just
> use distro kernels and distro configs, according to David, and I
> agree with that.

Well, the thing is, according to that logic, we might as well go back to
the pre-Kconfig language entirely.

I want people to feel that compiling their own kernel is *simple*.

I also feel that a lot of people are "advanced" in one area, but not
necessarily in another. The Netfilter example I gave was one such personal
gripe of mine. I just feel like I shouldn't need to care! Yeah, I have the
knowledge, but I *still* want to be baby-fed with just a simple "anybody
can understand it".

The same is true of the whole SATA/USB/SCSI thing. I know damn well that
the kernel uses the SCSI layer for USB and SATA, yet I feel that the ATA
layer does it right, and I just find the USB storage situation to be
*offensively* bad in this regard. Why the HELL does it have those big
comments and warnings, when it could just damn well enable SCSI support
itself?

So even advanced users aren't necessarily advanced outside their own
area of expertise (I have no clue what I2C crud I'd need for some DVB
card or even regular video card - or even *if* I need it). And even when
they are advanced, they don't mind simple questions.

This is not something where it's "good to be hard to use" (if those things
even exist anywhere else either..)

> > Claiming that "select" is evil is just totally strange.
>
> It's a real problem for developers who actually try to modify
> configs.

Why? You could *trivially* have a tool tell you. Make "xconfig" or
something just pop up a window saying "sorry, you can't disable SCSI,
because you've got ATA enabled, and ATA wants SCSI".

What's the big deal, here?

Linus

2007-02-05 23:21:51

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 2007-02-05 at 15:09 -0800, Linus Torvalds wrote:
> I also feel that a lot of people are "advanced" in one area, but not
> necessarily in another. The Netfilter example I gave was one such personal
> gripe of mine. I just feel like I shouldn't need to care! Yeah, I have the
> knowledge, but I *still* want to be baby-fed with just a simple "anybody
> can understand it".

The netfilter example is totally irrelevant here, since 'select' is
neither necessary nor sufficient for that. Russell and I have both
pointed that out to you already.

> Why? You could *trivially* have a tool tell you. Make "xconfig" or
> something just pop up a window saying "sorry, you can't disable SCSI,
> because you've got ATA enabled, and ATA wants SCSI".
>
> What's the big deal, here?

Mostly that for the benefit of users who really don't actually configure
their own kernels at all, we're screwing over the people who _do_, and
who want this to work like it always did:

sed -i -e 's/CONFIG_I2C=.*/# CONFIG_I2C is not set/' .config
make oldconfig

Not only does that not work like it always did, but it's also _really_
hard to find out why, on occasion. You have to grep all over the tree to
find the offending 'select' statement.

The other reason that a bunch of us are objecting is because we seem to
be doing this for very little real benefit -- if we wanted to pander to
Aunt Tillie, we could have done it in the tools. As I said, that was
working ten years ago. Maybe not merged back into your tree but working
nonetheless. It's not rocket science.

But Alan makes a reasonable suggestion -- we could work around this in
the tools too. I think you're very misguided in optimising for the
people who aren't likely to be configuring their own kernels anyway, but
despite the fact that others seem to agree with me, I don't hold out
much hope of changing your mind. If we can hack up the kconfig library
to work around this bogosity by (optionally) treating all 'select' of
visible symbols as 'depends on' instead, then I think that should
actually work OK.

--
dwmw2

2007-02-05 23:32:50

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 5 Feb 2007, David Woodhouse wrote:
>
> The netfilter example is totally irrelevant here, since 'select' is
> neither necessary nor sufficient for that. Russell and I have both
> pointed that out to you already.

No, the example IS relevant.

Why?

Because you don't seem to be getting the whole "be nice" part.

You continually argue as if being nice isn't an issue, and shouldn't be
even an option.

And maybe you can do it without select for netfilter, but you sure as HELL
cannot do it for things like SCSI and the USB/ATA question.

So you keep on ignoring the real argument, by belittling it.

You talk about "Aunt Tillie".

Don't talk about Aunt Tillie. Dammit! Talk about ME!

And talk about the kinds of people we *want* to compile the kernel: people
who may be entirely regular users, but people who want to help us debug
things by testing the -rc1 release.

Those people are IMPORTANT. You belittling the whole concept just makes
you look like an ass.

> Not only does that not work like it always did, but it's also _really_
> hard to find out why, on occasion.

And I told you that you could just improve the tools that track those
dependencies ANYWAY!

But what do you do? You just ignore it, talk about sed/grep, and bring up
your Aunt Tillie again.

Guess what? Maybe Aunt Tillie really *could* compile her own kernel.

But even more importantly, you have both the expertise and the knowledge
to make _your_ gripes go away, without having to just belittle and ignore
everybody elses concerns.

In other words, just make xconfig/gconfig/menuconfig/whatever say "Oops,
I'm not going to disable i2c because of the following dependency: ..."
and what is your problem?

And don't tell me about Aunt Tillie or about how you refuse to do anything
but grep's and sed's. If THAT is your problem, then you're barking up the
wrong tree.

Linus

2007-02-06 00:00:32

by Jeff Garzik

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

Linus Torvalds wrote:
> I also feel that a lot of people are "advanced" in one area, but not
> necessarily in another. The Netfilter example I gave was one such personal
> gripe of mine. I just feel like I shouldn't need to care! Yeah, I have the
> knowledge, but I *still* want to be baby-fed with just a simple "anybody
> can understand it".

It's a good example. I had a bear of a time with the netfilter kernel
config on my firewall (w/ IPv6 goodness) box, when the generic netfilter
stuff landed. For the first time in a long time, that firewall booted
into a configuration that wouldn't forward+masq packets properly.

> The same is true of the whole SATA/USB/SCSI thing. I know damn well that
> the kernel uses the SCSI layer for USB and SATA, yet I feel that the ATA
> layer does it right, and I just find the USB storage situation to be
> *offensively* bad in this regard. Why the HELL does it have those big
> comments and warnings, when it could just damn well enable SCSI support
> itself?

I think maybe ATA is just lucky. I allowed myself to get bullied into
avoiding 'select', even though I feel the same way as you.

ATA should select scsi-disk but doesn't, for example.

And at some point it becomes a matter of taste: should ATA select
BLOCK, or depend on BLOCK? There are IMO good arguments either way.

Jeff

2007-02-06 00:04:09

by Mark D Rustad

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote:

<snip>

> And I told you that you could just improve the tools that track those
> dependencies ANYWAY!

They aren't that bad even now. Using menuconfig (I'm a fossil that
just uses curses for most things), hitting ? shows what depends or
selects any particular entry. That is good enough for me now. Maybe I
am just willing to ask for help, but the help already seems to be there.

<snip>

--
Mark Rustad, [email protected]

2007-02-06 01:10:18

by Theodore Ts'o

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, Feb 05, 2007 at 11:21:34PM +0000, David Woodhouse wrote:
> But Alan makes a reasonable suggestion -- we could work around this in
> the tools too.

I wouldn't call it "work around this" in the tools. It's a useful
feature we can add in the tools for developers who aren't men enough
to use "sed/grep" pipelines. :-)

But I have to agree with Linus here that we should be optimizing the
tools for people who know how to compile the kernel, but who aren't
necessarily familiar with all of the hidden dependencies in the
literally hundreds of config options in the kernel tree. In reality,
you want to make it easy to turn on *or* off any arbitrary config
option, and to understand what you need to do so you can turn an
arbitrary config option on or off. If that means tools enhancements,
so be it.
- Ted

2007-02-06 05:59:10

by Matt Mackall

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, Feb 05, 2007 at 09:17:52PM +0000, David Woodhouse wrote:
> On Mon, 2007-02-05 at 08:58 -0800, Linus Torvalds wrote:
> > More importantly, some things that *are* visible probably shouldn't be, or
> > should perhaps only be in expert mode (aka "EMBEDDED").
>
> I've heard some fairly stupid abuse of the term 'embedded' in my time,
> but rarely have I heard people daft enough to abuse it to mean 'expert'.
> But yes, that's what we use CONFIG_EMBEDDED for.

I'd be happy to turn this into CONFIG_NONSTANDARD or
CONFIG_EXPERT, which is how I described it in the Kconfig help texts:

menuconfig EMBEDDED
bool "Configure standard kernel features (for small systems)"
help
This option allows certain base kernel options and settings
to be disabled or tweaked. This is for specialized
environments which can tolerate a "non-standard" kernel.
Only use this if you really know what you are doing.

A number of current users are indeed bogus. Stuff like:

config SUPERH
bool
default y
select EMBEDDED

Just because you're using a SuperH board doesn't mean you want to turn
off standard features.

--
Mathematics is the supreme nostalgia of our time.

2007-02-06 06:22:27

by Matt Mackall

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, Feb 05, 2007 at 08:09:58PM -0500, Theodore Tso wrote:
> On Mon, Feb 05, 2007 at 11:21:34PM +0000, David Woodhouse wrote:
> > But Alan makes a reasonable suggestion -- we could work around this in
> > the tools too.
>
> I wouldn't call it "work around this" in the tools. It's a useful
> feature we can add in the tools for developers who aren't men enough
> to use "sed/grep" pipelines. :-)
>
> But I have to agree with Linus here that we should be optimizing the
> tools for people who know how to compile the kernel, but who aren't
> necessarily familiar with all of the hidden dependencies in the
> literally hundreds of config options in the kernel tree. In reality,
> you want to make it easy to turn on *or* off any arbitrary config
> option, and to understand what you need to do so you can turn an
> arbitrary config option on or off. If that means tools enhancements,
> so be it.

With apt (or presumably with yum), you can happily apt-remove
a package that nothing else depends on. If you remove something that
other things depend on, you get a list of those things and opportunity
to force it (with a -f flag, for instance). If you ask for a package
that has other dependencies, it automatically pulls all those things
in unless there's a conflict. In which case you can force it again.

There's no reason we shouldn't be able to do exactly that with config
symbols in Kconfig-land. The only difference is that we've got
slightly different semantics for our "depend" keyword. Things which
don't have their "depend" requirements met aren't offered as options.
Whereas "select" is "automatically pull in dependencies"
apt/yum-style.

While we're at it, it would also be nice to be able to do:

$ kconfig enable ACPI
CONFIG_ACPI conflicts with CONFIG_APM
$ kconfig enable -F ACPI
disabling CONFIG_APM
$ kconfig disable SCSI
CONFIG_USB_STORAGE depends on CONFIG_SCSI
$ kconfig disable -f SCSI
disabling USB_STORAGE
$ make

--
Mathematics is the supreme nostalgia of our time.

2007-02-06 09:45:46

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 2007-02-05 at 15:32 -0800, Linus Torvalds wrote:
> On Mon, 5 Feb 2007, David Woodhouse wrote:
> >
> > The netfilter example is totally irrelevant here, since 'select' is
> > neither necessary nor sufficient for that. Russell and I have both
> > pointed that out to you already.
>
> No, the example IS relevant.
>
> Why?
>
> Because you don't seem to be getting the whole "be nice" part.

If you'd come down from your high horse for a moment you might realise
that I _agree_ with the 'be nice' part, as long as you don't pessimise
things for those who _do_ know what they're doing.

The thing you want for netfilter is a _GOOD IDEA_. I agree. I've even
implemented something _very_ similar, for JFFS2 compression options. If
you want to play about with individual compressors you have to enable
the 'Advanced options' first; otherwise you get the sane defaults.
Unless you really want to get your hands dirty, you don't have to know
which compressors we use by default.

It's a bad example because it's not relevant to the 'select' question,
and you're trying to use it as a straw man; assigning to me a belief I
just don't have.

> You continually argue as if being nice isn't an issue, and shouldn't be
> even an option.

Perhaps I haven't spoken carefully enough. I mean to argue that being
nice is good -- but that we shouldn't do so in a way which _costs_ those
who use the system most.

> And maybe you can do it without select for netfilter, but you sure as HELL
> cannot do it for things like SCSI and the USB/ATA question.

No, you really aren't paying attention. You CAN DO IT WITHOUT SELECT.

My point is not that we shouldn't be helpful. My point is that 'select'
is the _wrong_ way to be 'helpful', because that's a PITA for other
people. My point is that if we _want_ someone less experienced to be
able to see 'SCSI' light up automatically when they enable USB_STORAGE,
then we can do that IN THE TOOLS, as was demonstrated quite capably a
decade ago by the Nemesis folks.

But you're obviously not actually interested in reading what people say,
so I fully expect you to again pick one sentence out of the above and go
off at a tangent with a straw man again. So forget it. At least some
guidance on when to use depends vs. select _has_ come out of the thread,
which can be written up in Documentation/ and referred to later. That
should at least improve the _completely_ arbitrary use of 'select' we
currently see, such as the patch which started this thread. And I'll go
fix the kconfig tools to have an option for treating all 'select' of
user-visible options as dependencies, but the benefit of the people who
are the _normal_ users of Kconfig stuff.

--
dwmw2

2007-02-06 09:51:26

by Thierry Vignaud

[permalink] [raw]

Subject: Re: [2.6.20] Regression in dmfe driver

Thomas B?chler <[email protected]> writes:

> Commit 7628b0a8c01a02966d2228bdf741ddedb128e8f8 (drivers/net/tulip/dmfe:
> support basic carrier detection) breaks networking on my Davicom DM9009.
> ethtool always reports there is no link. tcpdump shows incoming packets,
> but TX is disabled. Reverting the above patch fixes the problem.

disable link detection in your network config then (eg:
MII_NOT_SUPPORTED=yes in ifcfg-XXX depending on the distro).

2007-02-06 13:32:25

by Gerhard Mack

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 5 Feb 2007, Ingo Oeser wrote:

> On Monday, 5. February 2007, Linus Torvalds wrote:
> > So thank God for the few selects we have, and we should add a whole lot
> > more!
>
> But "select" is not fine grained enough.
>
> I would like to have "require", "recommend", "suggest" for feature A.
>
> require X
> does not work without X, but X is way down the tree
> e.g. ext3 and block device or how select currently is intended
>
> recommend X
> it is usable but uncomfortable without X, enabled per default
> e.g. firewalling recommends connection tracking support
> or NAT recommends all NAT helpers
>
> suggest X
> many people use A together with X,
> so you might be interested in enabling it, but I disabled it
> per default unless you said "featuritis mode" before.
> e.g. highmem and SMP or a network driver and NAPI.
>
> That is what the Debian/Ubuntu package management does and maybe other too.
> And this also gives us new keywords to replace select with,
> so migration is doable :-)
>
> This would also make "EMBEDDED" superflous, because it would just mean
> "disable anything not required".
>
> And this would enable an individual tree for the users current configuration
> problem instead of a global one.

I think "package manager" is the best possible way to think about this
problem.

I can't tell you how often I've wished the kernel config process behaved
like apt and just prompted me with a list of things it would need to
enable to allow me to use the option and ask me if I still want to do it.
The reverse when I try and remove something important would be good too
just ask me if I really want to remove all those as well.

A functional equivelant of deborphan would be cool too. Just run it and
have it tell me what is enabled that no devices depend on.

The config system is nasty even for power users. There is a fun part of
the netfilter code where I find myself having to enable all from one menu,
go to the next menu down enable everything and then go back to the first
menu.

Gerhard

--
Gerhard Mack

[email protected]

<>< As a computer I find your faith in technology amusing.

2007-02-06 14:36:56

by Jörn Engel

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, 5 February 2007 15:09:15 -0800, Linus Torvalds wrote:
>
> Why? You could *trivially* have a tool tell you. Make "xconfig" or
> something just pop up a window saying "sorry, you can't disable SCSI,
> because you've got ATA enabled, and ATA wants SCSI".

That would be useful for both select and depend, as many have pointed
out. And ignoring the fairly subjective "be nice" part, either select
or depend can completely get removed once the tools have it.

What I disagree with is the *trivially* part. For one, the problem is
known for some time and has annoyed enough people, yet we don't have
patches yet. Secondly, we'd need patches for most, if not all tools.
Not having used "xconfig" for the last eight years, I doubt that you'd
reach a majority of users with any of the plethora of make *config
targets.

We _need_ this support and I welcome anyone getting his/her hands dirty
writing it up.

Jörn

--
Fantasy is more important than knowledge. Knowledge is limited,
while fantasy embraces the whole world.
-- Albert Einstein

2007-02-06 15:16:19

by Mark Lord

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

I'm with Linus 100% here.

It's really irritating to upgrade to a newer kernel,
using the same old .config file, and then discover that
my MythTV box no longer auto-boots to record programs.

The reason being, that /proc/acpi/alarm no longer exists,
and the kernel option to configure it has mysteriously
disappeared from the menus.

After an hour of hand examining and grep'ing Kconfig files,
I eventually find the secret little totally-unrelated option
that has to be selected to make the ACPI alarm option visible
again.

Doh!

That interface is driven entirely backwards.
The funtionality option should always be visible,
and should "select" (or hey, invent a better mechanism,
I'm not fussy), the underlying crap required to let me use it.

Cheers

2007-02-06 15:36:13

by Paul Mundt

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Mon, Feb 05, 2007 at 11:46:12PM -0600, Matt Mackall wrote:
> I'd be happy to turn this into CONFIG_NONSTANDARD or
> CONFIG_EXPERT, which is how I described it in the Kconfig help texts:
>
> menuconfig EMBEDDED
> bool "Configure standard kernel features (for small systems)"
> help
> This option allows certain base kernel options and settings
> to be disabled or tweaked. This is for specialized
> environments which can tolerate a "non-standard" kernel.
> Only use this if you really know what you are doing.
>
> A number of current users are indeed bogus. Stuff like:
>
> config SUPERH
> bool
> default y
> select EMBEDDED
>
> Just because you're using a SuperH board doesn't mean you want to turn
> off standard features.
>
The only thing bogus is the CONFIG_EMBEDDED use itself, if it were only
limited to turning options off, you'd be correct, but both PCI and IDE
use it for other things. We specifically wanted it for IDE in this case.

I'd be quite happy to see CONFIG_EMBEDDED separated entirely from the
"advanced/expert/screwing aunt tillie" selection menu, or whatever we're
choosing to call it these days. Then we wouldn't have to deal with these
confusing defconfigs that expose far more than most users are going to
care about.

There are a number of other architectures that do this too, so it may be
worth separating so we can finally get rid of the confusion.

2007-02-06 15:41:32

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

Linus Torvalds wrote:
>
> On Mon, 5 Feb 2007, David Woodhouse wrote:
>> Ten years ago, people used 'depends on' to fix the tools, so that then
>> you want to enable something like USB_STORAGE, it can automatically turn
>> SCSI on for you.
>>
>> Isn't that what you wanted?
>
> Try it. It's not what it does.
>
> If you have a
>
> depends on SCSI
>
> and you did not say you wanted SCSI, you'll never even *see* the question.
>
> It will *not* turn on SCSI automatically for you. Quite the reverse. It
> will not even show you the option.

My favorite example of this is selinux, which you don't see unless you
enable other unobvious things first. I say unobvious because until you
do it the first few times you don't see the option, you ask menuconfig
where it is, and it isn't there. So you go use your favorite tool to
search the Kconfig until you find out why.

Now that's in part a failure of the menuconfig tool I use, which may not
be in xconfig (I'll try that later today when I build a new kernel), but
it seem odd that a major feature would not show unless something obscure
were selected, and that the crypto features needed for selinux would be
good candidates for SELECT.

Just because config is something mostly done by advanced user doesn't
mean it should be difficult or time-consuming.

And why say "should have done" for the SCSI mess, it's correctable, if
everyone agrees that you are right (who would dare disagree ;-) then it
can be fixed.

--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot

2007-02-06 15:53:23

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

David Woodhouse wrote:
> On Mon, 2007-02-05 at 15:32 -0800, Linus Torvalds wrote:
>> On Mon, 5 Feb 2007, David Woodhouse wrote:
>>> The netfilter example is totally irrelevant here, since 'select' is
>>> neither necessary nor sufficient for that. Russell and I have both
>>> pointed that out to you already.
>> No, the example IS relevant.
>>
>> Why?
>>
>> Because you don't seem to be getting the whole "be nice" part.
>
> If you'd come down from your high horse for a moment you might realise
> that I _agree_ with the 'be nice' part, as long as you don't pessimise
> things for those who _do_ know what they're doing.
>
> The thing you want for netfilter is a _GOOD IDEA_. I agree. I've even
> implemented something _very_ similar, for JFFS2 compression options. If
> you want to play about with individual compressors you have to enable
> the 'Advanced options' first; otherwise you get the sane defaults.
> Unless you really want to get your hands dirty, you don't have to know
> which compressors we use by default.

One thing which can be solved at the tool level, particularly for
netfilter, is to provide options for "turn it all of and I'll select,"
"turn it all on (or module)," and "reset this page to defaults." Because
those starting points will cover a majority of the options. Useful for
device drivers as well, particularly network cards and disk controllers,
where there are a vast number of choices.

--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot

2007-02-06 15:55:16

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

Mark Rustad wrote:
> On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote:
>
> <snip>
>
>> And I told you that you could just improve the tools that track those
>> dependencies ANYWAY!
>
> They aren't that bad even now. Using menuconfig (I'm a fossil that just
> uses curses for most things), hitting ? shows what depends or selects
> any particular entry. That is good enough for me now. Maybe I am just
> willing to ask for help, but the help already seems to be there.
>
I think the problem Linus referenced with not even seeing an option is
an issue, you can't "?" on an option you can't see. An I use menuconfig
also, from long habit (accessing a remote compile server with slow dialup).

--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot

2007-02-06 16:04:54

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

Matt Mackall wrote:
> On Mon, Feb 05, 2007 at 08:09:58PM -0500, Theodore Tso wrote:
>> On Mon, Feb 05, 2007 at 11:21:34PM +0000, David Woodhouse wrote:
>>> But Alan makes a reasonable suggestion -- we could work around this in
>>> the tools too.
>> I wouldn't call it "work around this" in the tools. It's a useful
>> feature we can add in the tools for developers who aren't men enough
>> to use "sed/grep" pipelines. :-)
>>
>> But I have to agree with Linus here that we should be optimizing the
>> tools for people who know how to compile the kernel, but who aren't
>> necessarily familiar with all of the hidden dependencies in the
>> literally hundreds of config options in the kernel tree. In reality,
>> you want to make it easy to turn on *or* off any arbitrary config
>> option, and to understand what you need to do so you can turn an
>> arbitrary config option on or off. If that means tools enhancements,
>> so be it.
>
> With apt (or presumably with yum), you can happily apt-remove
> a package that nothing else depends on. If you remove something that
> other things depend on, you get a list of those things and opportunity
> to force it (with a -f flag, for instance). If you ask for a package
> that has other dependencies, it automatically pulls all those things
> in unless there's a conflict. In which case you can force it again.
>
> There's no reason we shouldn't be able to do exactly that with config
> symbols in Kconfig-land. The only difference is that we've got
> slightly different semantics for our "depend" keyword. Things which
> don't have their "depend" requirements met aren't offered as options.
> Whereas "select" is "automatically pull in dependencies"
> apt/yum-style.

Perhaps this is because there is a lacking keyword. The depends controls
visibility, perhaps a "requires" could be used to provide advisory
information which mean "these other things will be turned on if you
build this feature."
>
> While we're at it, it would also be nice to be able to do:
>
> $ kconfig enable ACPI
> CONFIG_ACPI conflicts with CONFIG_APM
> $ kconfig enable -F ACPI
> disabling CONFIG_APM
> $ kconfig disable SCSI
> CONFIG_USB_STORAGE depends on CONFIG_SCSI
> $ kconfig disable -f SCSI
> disabling USB_STORAGE
> $ make
>
I think depends and select provide this now, the postulated "requires"
might make building the trees easier.

--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot

2007-02-06 16:21:00

by Mark D Rustad

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Feb 6, 2007, at 9:55 AM, Bill Davidsen wrote:

> Mark Rustad wrote:
>> On Feb 5, 2007, at 5:32 PM, Linus Torvalds wrote:
>> <snip>
>>> And I told you that you could just improve the tools that track
>>> those
>>> dependencies ANYWAY!
>> They aren't that bad even now. Using menuconfig (I'm a fossil that
>> just uses curses for most things), hitting ? shows what depends or
>> selects any particular entry. That is good enough for me now.
>> Maybe I am just willing to ask for help, but the help already
>> seems to be there.
> I think the problem Linus referenced with not even seeing an option
> is an issue, you can't "?" on an option you can't see. An I use
> menuconfig also, from long habit (accessing a remote compile server
> with slow dialup).

Yes, of course. My point was that if you are "the embedded guy" (like
I often am) trying to turn something off, the tools show you what to
look at already. They are currently no help if the option does not
appear, as you say. So automatically selecting things that are
required for something is much better than hiding too much. At least
it is easy to find out why something is selected if you really want
to turn it off.

If more things worked as Linus suggests, I don't think the tools need
much in the way of improvement. It really is more about how they are
used as they are. That is not to say that tools improvements are not
always welcome, but the current tools seem to work pretty well.

--
Mark Rustad, [email protected]

2007-02-06 16:53:59

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 6 Feb 2007, David Woodhouse wrote:
>
> It's a bad example because it's not relevant to the 'select' question,
> and you're trying to use it as a straw man; assigning to me a belief I
> just don't have.

It *is* relevant.

Why are you ignoring the ATA example? Which is exactly the same thing?
(And where we do the right thing - we just "select SCSI")

Why are you ignoring the USB example - which is exactly the same thing
(and where we do the *wrong* thing: we "depend on SCSI" and then we have
about 5 lines of warning both around USB and around SCSI and documentation
just to say that USB needs it!)

> Perhaps I haven't spoken carefully enough. I mean to argue that being
> nice is good -- but that we shouldn't do so in a way which _costs_ those
> who use the system most.

It costs you nothing but arguing.

> No, you really aren't paying attention. You CAN DO IT WITHOUT SELECT.

No, I was paying attention. You seem to just be obtuse on purpose.

WE WANT TO BE NICE.
- the firewall example was not an example of 'select', but of the "we
want to be nice". But you simply DID NOT GET IT.
- the USB and SATA examples are *also* examples of "we want to be nice",
and hell yeah, you need 'select' to do them. Claiming anything else is
just stupid.

So: are you stupid, or do you just refuse to even think about it?

> My point is not that we shouldn't be helpful. My point is that 'select'
> is the _wrong_ way to be 'helpful', because that's a PITA for other
> people.

It's a PITA just because you don't listen, and ignore everything I say.

In other words, the problem is *you*.

The problem is NOT "select".

People have even pointed out that you don't even have to create new tools.
Use menuconfig and "?", which apparently already tells you what the
dependencies are, and why you can't turn something off..

And yes, I just tried. I couldn't turn SCSI off in menuconfig, so I
pressed '?', and at the end it does actually say:

Selected by: ATA && BLOCK && (!M32R && !M68K || BROKEN) && (!SUN4 || BROKEN)

Not hugely readable, and I'm sure it could be improved a lot.

And yes, I certainly think that it would be a good idea if there would be
other tools that told you too. The Kconfig engine *internally* already
knows all this, of course, so all the hard work has already effectively
been done, it's just not *shown*.

So you should just face it: the problem *really* isn't 'select'.

Linus

2007-02-06 16:54:29

by Matt Mackall

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, Feb 06, 2007 at 11:04:31AM -0500, Bill Davidsen wrote:
> >There's no reason we shouldn't be able to do exactly that with config
> >symbols in Kconfig-land. The only difference is that we've got
> >slightly different semantics for our "depend" keyword. Things which
> >don't have their "depend" requirements met aren't offered as options.
> >Whereas "select" is "automatically pull in dependencies"
> >apt/yum-style.
>
> Perhaps this is because there is a lacking keyword. The depends controls
> visibility, perhaps a "requires" could be used to provide advisory
> information which mean "these other things will be turned on if you
> build this feature."

"require" is a bad name as it's a synonym of "depend".

> >While we're at it, it would also be nice to be able to do:
> >
> >$ kconfig enable ACPI
> >CONFIG_ACPI conflicts with CONFIG_APM
> >$ kconfig enable -F ACPI
> >disabling CONFIG_APM
> >$ kconfig disable SCSI
> >CONFIG_USB_STORAGE depends on CONFIG_SCSI
> >$ kconfig disable -f SCSI
> >disabling USB_STORAGE
> >$ make
> >
> I think depends and select provide this now, the postulated "requires"
> might make building the trees easier.

The above is all about having a scriptable command line interface so
that people don't need the broken sed + make oldconfig thing.

--
Mathematics is the supreme nostalgia of our time.

2007-02-06 18:05:34

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

Matt Mackall wrote:
> On Tue, Feb 06, 2007 at 11:04:31AM -0500, Bill Davidsen wrote:
>
>>> There's no reason we shouldn't be able to do exactly that with config
>>> symbols in Kconfig-land. The only difference is that we've got
>>> slightly different semantics for our "depend" keyword. Things which
>>> don't have their "depend" requirements met aren't offered as options.
>>> Whereas "select" is "automatically pull in dependencies"
>>> apt/yum-style.
>>>
>> Perhaps this is because there is a lacking keyword. The depends controls
>> visibility, perhaps a "requires" could be used to provide advisory
>> information which mean "these other things will be turned on if you
>> build this feature."
>>
>
> "require" is a bad name as it's a synonym of "depend".
>
>
>>> While we're at it, it would also be nice to be able to do:
>>>
>>> $ kconfig enable ACPI
>>> CONFIG_ACPI conflicts with CONFIG_APM
>>> $ kconfig enable -F ACPI
>>> disabling CONFIG_APM
>>> $ kconfig disable SCSI
>>> CONFIG_USB_STORAGE depends on CONFIG_SCSI
>>> $ kconfig disable -f SCSI
>>> disabling USB_STORAGE
>>> $ make
>>>
>>>
>> I think depends and select provide this now, the postulated "requires"
>> might make building the trees easier.
>>
>
> The above is all about having a scriptable command line interface so
> that people don't need the broken sed + make oldconfig thing.
>
>
I didn't say that clearly, I meant that the information to do this was
present, not the functionality.

Someone suggested that 'requires' was a synonym of 'depends on' and was
a bad choice. I think the requirement is in fasct the same, what I was
after was not to prevent visibility of the option as 'depends' does. And
we still probably need depends to avoid way too many choices.

--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979

2007-02-06 19:07:26

by Stephen Hemminger

[permalink] [raw]

Subject: Re: Super Kernel Sunday!

On Mon, 5 Feb 2007 18:58:39 +0100 (MET)
Jan Engelhardt <[email protected]> wrote:

> Hi,
>
>
> >VERSION = 2
> >PATCHLEVEL = 6
> >SUBLEVEL = 20
> >EXTRAVERSION =
> >NAME = Homicidal Dwarf Hamster
>
> Bah! And I had expected "Super Sunday Kernel" here. :>
>
> BTW: is @osdl.org still valid?

Yes, the email address will be forwarded to linux-foundation.org for
the foreseeable future.

--
Stephen Hemminger <[email protected]>

2007-02-06 22:38:20

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 2007-02-06 at 08:53 -0800, Linus Torvalds wrote:
>
> WE WANT TO BE NICE.
> - the firewall example was not an example of 'select', but of the "we
> want to be nice". But you simply DID NOT GET IT.

It's a very clever straw man, Linus, but it's still bogus. Not only do I
_agree_ about the firewall example, I've even implemented very similar
things already, of my own accord. I really do get it.

I don't claim that we shouldn't "be nice". You keep coming back to that
but it bears no relation to what I'm actually saying.

> - the USB and SATA examples are *also* examples of "we want to be nice",
> and hell yeah, you need 'select' to do them. Claiming anything else is
> just stupid.
>
> So: are you stupid, or do you just refuse to even think about it?

I claim that there are _better_ ways to do it than 'select'. I claim
that we can 'be nice' without actually screwing over the people who use
non-interactive config methods and need to turn stuff off. A number of
whom have spoken up already but are perhaps less quixotic than I am so
have given up on getting you to listen.

99% of the times I configure a kernel, it's in an RPM package. The
answer "you can use xconfig and press the question mark" isn't
wonderfully useful -- although having xconfig be the answer for those
who need the extra guidance that 'select' currently offers is perhaps a
more reasonable solution.

But it doesn't matter. I'll come up with a hack for the tools which make
them (optionally) treat 'select' of a user-visible option as if it was
just 'depends on'. And that should fix the problem.

--
dwmw2

2007-02-06 22:39:29

by Håvard Skinnemoen

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On 2/6/07, Matt Mackall <[email protected]> wrote:
> A number of current users are indeed bogus. Stuff like:
>
> config SUPERH
> bool
> default y
> select EMBEDDED
>
> Just because you're using a SuperH board doesn't mean you want to turn
> off standard features.

I disagree. I did the exact same thing on AVR32 because !EMBEDDED
forces on tons of crap that just isn't useful on many embedded
platforms. I trust our users to actually enable for example virtual
terminal support if they happen to need it. Far from everyone do, and
it's going to end up as dead code unless they also enable the right
framebuffer driver.

Haavard

2007-02-06 22:40:28

by Thomas Bächler

[permalink] [raw]

Subject: Re: [2.6.20] Regression in dmfe driver

Thierry Vignaud schrieb:
> disable link detection in your network config then (eg:
> MII_NOT_SUPPORTED=yes in ifcfg-XXX depending on the distro).

I don't have such an option in "my distro". What does it do and how
would it change the fact that TX is being disabled in the driver?

2007-02-06 22:44:23

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 06 Feb 2007 22:38:04 +0000 David Woodhouse wrote:

> On Tue, 2007-02-06 at 08:53 -0800, Linus Torvalds wrote:
> >
> > WE WANT TO BE NICE.
> > - the firewall example was not an example of 'select', but of the "we
> > want to be nice". But you simply DID NOT GET IT.
>
> It's a very clever straw man, Linus, but it's still bogus. Not only do I
> _agree_ about the firewall example, I've even implemented very similar
> things already, of my own accord. I really do get it.
>
> I don't claim that we shouldn't "be nice". You keep coming back to that
> but it bears no relation to what I'm actually saying.
>
> > - the USB and SATA examples are *also* examples of "we want to be nice",
> > and hell yeah, you need 'select' to do them. Claiming anything else is
> > just stupid.
> >
> > So: are you stupid, or do you just refuse to even think about it?
>
> I claim that there are _better_ ways to do it than 'select'. I claim
> that we can 'be nice' without actually screwing over the people who use
> non-interactive config methods and need to turn stuff off. A number of
> whom have spoken up already but are perhaps less quixotic than I am so
> have given up on getting you to listen.

Even with the interactive tools it's difficult to turn symbols off
if they are selected in multiple places. But that's the old tools
issue.

But Andrew has done a great job of trying to minimize 'select'
in Kconfig files.

> 99% of the times I configure a kernel, it's in an RPM package. The
> answer "you can use xconfig and press the question mark" isn't
> wonderfully useful -- although having xconfig be the answer for those
> who need the extra guidance that 'select' currently offers is perhaps a
> more reasonable solution.
>
> But it doesn't matter. I'll come up with a hack for the tools which make
> them (optionally) treat 'select' of a user-visible option as if it was
> just 'depends on'. And that should fix the problem.

Yes, that's the solution that I decided on during lunch also:
select <==> depends on

---
~Randy

2007-02-06 22:52:25

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 6 Feb 2007, Haavard Skinnemoen wrote:
>
> I disagree. I did the exact same thing on AVR32 because !EMBEDDED
> forces on tons of crap that just isn't useful on many embedded
> platforms.

I do agree. EMBEDDED largely means "non-generic/non-standard" these days.
It's also true that EMBEDDED does *not* necessarily mean "small", since
some of the choices that it disables can often be choices that you want on
*big* machines.

For example, the whole thing where VGA and keyboard/mouse support default
to on when EMBEDDED isn't selected is quite possibly a good reason to
enable EMBEDDED on big servers that aren't even meant to be general-
purpose, but simply optimized for a particular environment.

That is, technically, what "embedded" really means. A lot of the time
people talk about it as if it was always "small", but it can be a big
computer that is just used in a very specific turn-key environment where
some of the default kernel choices may not be sensible.

Linus

2007-02-06 22:54:05

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 6 Feb 2007, David Woodhouse wrote:
>
> I claim that there are _better_ ways to do it than 'select'.

I don't think you've ever showed any such example.

And if you did, it would all boil down to *exactly* what 'select' does:
config options that get set automatically based on other choices.

So care to give a real example? Start with USB automatically selecting
SCSI support without the user having to even know it uses SCSI. Tell me
how it's supposed to work sanely without 'select'.

Put up, or shut up.

Linus

2007-02-06 23:11:36

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 6 Feb 2007, Randy Dunlap wrote:
>
> Yes, that's the solution that I decided on during lunch also:
> select <==> depends on

I think yuou can certainly enable an "expert mode", which just reads
"select" as "depends on".

You'll probably have to do *more* changes to the tools than my suggestion
to just make them let you know why they can't turn something off, though.
Why? Some things don't even have questions at all right now, and their
only life is as implied options that are turned on by others.

And yes, some silly people who hate "select" have tried to turn them into

bool SUBSYSTEM
default y
depends on X || Y || Z || XY || XZ || YZ

or similar, which is a hell of a lot less maintainable than just letting
X, Y, Z etc do 'select SUBSYSTEM'.

But "select SUBSYSTEM" still does exist, notably in places like SND_PCM
(where it would just be INSANE to list all the different sound drivers
that want it as a shitload of "depends on") but also for things like
NET_CLS and CRYPTO etc.

Linus

2007-02-06 23:12:05

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 2007-02-06 at 14:53 -0800, Linus Torvalds wrote:
> I don't think you've ever showed any such example.
>
> And if you did, it would all boil down to *exactly* what 'select' does:
> config options that get set automatically based on other choices.

That's one option which I don't think I've seen implemented.

The other possibility which comes to mind, and which I _have_ seen
implemented, is not to hide the disabled option but to _show_ it, and
represent its dependencies right there next to it somehow.

Where I saw this done was actually in the Nemesis kernel configuration,
which was based on our old tcl xconfig tool. It actually worked quite
well. It's a _long_ time ago now, but IIRC it was in a cell below the
disabled option. It'd look something like (remember hte old xconfig?):

------------------------------------------------------------------------
| USB Mass storage support | o Y o M ✓ N |
------------------------------------------------------------------------
| depends on: o SCSI ✓ USB |
------------------------------------------------------------------------

I'm sure I had a screenshot of it once. But it doesn't matter; you get
the idea -- our current tools would do it differently anyway. But they
_could_ do it.

> So care to give a real example? Start with USB automatically selecting
> SCSI support without the user having to even know it uses SCSI. Tell me
> how it's supposed to work sanely without 'select'.

Well one option, as you suggest, is just that if you go into the
graphical tool and enable USB_STORAGE, you get SCSI turned on
automatically. That's simple enough and the xconfig tool can do it quite
easily. It just needs to _show_ you the option, which isn't particularly
hard. But what I care about is that when you when you explicitly set
# CONFIG_SCSI is not set
and run 'make oldconfig' it doesn't get turned back on again.

But as I said, I'm not entirely averse to having to do 'make
oldconfig-noselect' or something like that to preserve the old
behaviour. And then you can sprinkle 'select' wherever you like without
bothering those of us who object.

--
dwmw2

2007-02-06 23:16:10

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 6 Feb 2007, Linus Torvalds wrote:
>
> On Tue, 6 Feb 2007, Randy Dunlap wrote:
> >
> > Yes, that's the solution that I decided on during lunch also:
> > select <==> depends on
>
> I think yuou can certainly enable an "expert mode", which just reads
> "select" as "depends on".

Actually, it's probably more useful if you do it for a single symbol only.

If you really want to force something off, mark that *single* symbol as
having "select <that-symbol>" being translated into "depends on", and it
will probably work fine in practice.

Linus

2007-02-06 23:18:29

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 2007-02-06 at 15:11 -0800, Linus Torvalds wrote:
>
> On Tue, 6 Feb 2007, Randy Dunlap wrote:
> > > But it doesn't matter. I'll come up with a hack for the tools which make
> > > them (optionally) treat 'select' of a user-visible option as if it
> > > was just 'depends on'. And that should fix the problem.
> >
> > Yes, that's the solution that I decided on during lunch also:
> > select <==> depends on
>
> I think yuou can certainly enable an "expert mode", which just reads
> "select" as "depends on".
>
> You'll probably have to do *more* changes to the tools than my suggestion
> to just make them let you know why they can't turn something off, though.
> Why? Some things don't even have questions at all right now, and their
> only life is as implied options that are turned on by others.
>
> And yes, some silly people who hate "select" have tried to turn them into

Out of interest, which people would this be? Not me, certainly.
I _use_ select, for options which don't have questions. There were two
such instances in the context of Ingo's mail of $subject, even.

And the thing Randy was saying "yes" to, which you elided but I've
restored in the above quotation, was the idea of turning 'select' into
'depends on' for _user-visible_ options. NOT for the ones which don't
have a question.

--
dwmw2

2007-02-06 23:28:33

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 6 Feb 2007, David Woodhouse wrote:
>
> The other possibility which comes to mind, and which I _have_ seen
> implemented, is not to hide the disabled option but to _show_ it, and
> represent its dependencies right there next to it somehow.

That would probably work, especially if you had some way to "warp" to the
other options (so that if you see "depends on SCSI" you could say "ok, go
to SCSI then".

However, I have this suspicion that you'd just drown in options that you
really don't want to see.

> Well one option, as you suggest, is just that if you go into the
> graphical tool and enable USB_STORAGE, you get SCSI turned on
> automatically.

Yes. That basically is what "select" means, though. The difference is,
indeed, largely about visibility.

If everything was always visible, there really wouldn't be much of a
difference between "depends on" and "select". In both cases, when you
click on something that depends on or selects something else, the config
tool would obviously select it.

So yes, you can make "depends on" and "select" mean _exactly_ the same
thing. But basically only by always showing everything. Which I don't
think you want. If I say I don't want IPv6, I really am not interested in
seeing some IPv6-only questions. But on the other hand, maybe there is
something that _needs_ IPv6 to work, and then maybe I'd like it enabled..

(Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might
still want to be able to see the question about NFSv8.1, which only works
on top of IPV6. I might not even *know* I want IPV6, but I know my company
uses NFSv8.1, so I say "yes").

And I realize that was a contrieved example, but there are *real* examples
of this in the kernel today. I may well know that I want 802.11 WEP
encryption, for example, but I sure as hell had *no* clue that it requires
ARC4.

See the problem? I may be a well-educated user who doesn't even *know*
that I actually want an encrytion algorithm that I've never heard of. For
all I knew, the 802.11 WEP stuff was done inside the wireless cards by
hardware..

Does that mean that if I don't have CRYPTO_ARC4 enabled (which in turn
would need CRYPTO_ALGAPI enabled too) I'd not even get the choice of WEP?
Obviously that is broken.

And yes, if you *always* get the choice of *everyting*, then it all boils
down to the same thing. I just don't think you do..

Linus

2007-02-06 23:36:30

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 2007-02-06 at 15:28 -0800, Linus Torvalds wrote:
> (Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might
> still want to be able to see the question about NFSv8.1, which only works
> on top of IPV6. I might not even *know* I want IPV6, but I know my company
> uses NFSv8.1, so I say "yes").

(Quoting very sparsely but I think honestly -- I think the above is the
essence of what you were saying).

Actually it doesn't have to be that much of a problem if the config
stuff is laid out sensibly, as Ingo mentioned earlier. Those IPv6
options you don't want to see are likely to be all in an 'IPv6' submenu
of the networking stuff which nobody forces you to visit. Yet
'NFSv8.1' (*shudder*) would be elsewhere under networked file systems,
or some suboption of NFS, and you'd see it just fine.

> And I realize that was a contrieved example, but there are *real* examples
> of this in the kernel today. I may well know that I want 802.11 WEP
> encryption, for example, but I sure as hell had *no* clue that it requires
> ARC4.

Again, if you don't care about crypto then you're unlikely to be delving
in the crypto menus. Nobody forces you to go there. But when you look at
the greyed-out WEP option and you click on it and it tells you "You need
ARC4 for this. Do you want me to turn it on for you?" (or whatever), you
get what you wanted.

Really, if our config is set up in sensible submenus (as in general it
_is_), the "see everything" behaviour really isn't bad.

--
dwmw2

2007-02-06 23:47:15

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 06 Feb 2007 23:36:23 +0000 David Woodhouse wrote:

> On Tue, 2007-02-06 at 15:28 -0800, Linus Torvalds wrote:
> > (Example: I don't want to see IPV6 questions if IPV6 is off, BUT I might
> > still want to be able to see the question about NFSv8.1, which only works
> > on top of IPV6. I might not even *know* I want IPV6, but I know my company
> > uses NFSv8.1, so I say "yes").
>
> (Quoting very sparsely but I think honestly -- I think the above is the
> essence of what you were saying).
>
> Actually it doesn't have to be that much of a problem if the config
> stuff is laid out sensibly, as Ingo mentioned earlier. Those IPv6
> options you don't want to see are likely to be all in an 'IPv6' submenu
> of the networking stuff which nobody forces you to visit. Yet
> 'NFSv8.1' (*shudder*) would be elsewhere under networked file systems,
> or some suboption of NFS, and you'd see it just fine.
>
> > And I realize that was a contrieved example, but there are *real* examples
> > of this in the kernel today. I may well know that I want 802.11 WEP
> > encryption, for example, but I sure as hell had *no* clue that it requires
> > ARC4.
>
> Again, if you don't care about crypto then you're unlikely to be delving
> in the crypto menus. Nobody forces you to go there. But when you look at
> the greyed-out WEP option and you click on it and it tells you "You need
> ARC4 for this. Do you want me to turn it on for you?" (or whatever), you
> get what you wanted.
>
> Really, if our config is set up in sensible submenus (as in general it
> _is_), the "see everything" behaviour really isn't bad.

Well, there's layout and then there's the tool(s).

Besides this select business, Bill (or someone :) mentioned a feature
that I requested about 8 months ago: the ability to disable or enable
groups of drivers at one swoop. And Matt has made some good
scripting suggestions.

For layout, we may not all agree on that part either. :)
It's quite subjective. E.g., I made/submitted a patch maybe 1 year
ago that tried to put all video graphics (frame buffer, AGP, DRM/DRI,
etc.) into one localized place in the menu structure.
OK, perhaps I wasn't persistent enough, but no one was interested
in it. (That probably just means that config menus are low priority.)

---
~Randy

2007-02-06 23:49:15

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 2007-02-06 at 15:41 -0800, Randy Dunlap wrote:
> It's quite subjective. E.g., I made/submitted a patch maybe 1 year
> ago that tried to put all video graphics (frame buffer, AGP, DRM/DRI,
> etc.) into one localized place in the menu structure.
> OK, perhaps I wasn't persistent enough, but no one was interested
> in it. (That probably just means that config menus are low
> priority.)

Compared with making the bloody _code_ actually cooperate, in that
particular respect, I think the config options are indeed a fairly low
priority :)

--
dwmw2

2007-02-06 23:49:48

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 6 Feb 2007, David Woodhouse wrote:
>
> Out of interest, which people would this be? Not me, certainly.
> I _use_ select, for options which don't have questions. There were two
> such instances in the context of Ingo's mail of $subject, even.
>
> And the thing Randy was saying "yes" to, which you elided but I've
> restored in the above quotation, was the idea of turning 'select' into
> 'depends on' for _user-visible_ options. NOT for the ones which don't
> have a question.

Example: crypto api. SCSI. firewall "expert mode". Any number of things.

Qutie often, the questions themselves are *conditional*. For example, look
at the whole INPUT layer thing. It is a real question, but only for
EMBEDDED - normally, we just assume we'll use it (but it's a classic
example of where we could have used a "select" from the keyboard driver
instead).

For normal people, it's a question that simply shouldn't be asked. You
don't ask normal users whether they want to hook up keyboards and mice
(and trust me when I say that: we _used_ to ask. It generated tons of
totally idiotic noise).

Linus

2007-02-06 23:54:03

by Robert P. J. Day

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 6 Feb 2007, Randy Dunlap wrote:

> Besides this select business, Bill (or someone :) mentioned a
> feature that I requested about 8 months ago: the ability to disable
> or enable groups of drivers at one swoop.

i vaguely recall that *i* was pushing that idea, and even submitted a
couple patches to start the process, but it never really went
anywhere.

rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

2007-02-06 23:55:35

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 6 Feb 2007, David Woodhouse wrote:
>
> Really, if our config is set up in sensible submenus (as in general it
> _is_), the "see everything" behaviour really isn't bad.

There are two fundamental problems with that statement:

- no, it really isn't always

Quite often, our Kconfig files have dependencies that are about where
the *code* exists, rather than about some nice hierarchical system.

Think of it this way: would you use a programming language that didn't
allow you anything but totally hierarcical language constructs? No sane
person would - because real life isn't hierarchical. Yes, there are
many things that are, but not all things are.

Example: many cryptographic algorithms are in crypto/. But then a lot
of them ARE NOT. They are in arch/so-and-so/crypto/ or similar. Notice?

NOT HIERARCHICAL.

- I don't use menus at all. I use the good old textual "make oldconfig".
Trust me, I _want_ those irrelevant questions gone. They aren't "grayed
out".

So you seem to have this *wish* that real life was different than it is.
But we aren't hierarchical, and even if we were, it *still* wouldn't work
the way you want things to work.

Linus "reality bites" Torvalds

2007-02-07 00:03:50

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 2007-02-06 at 15:55 -0800, Linus Torvalds wrote:
>
> On Tue, 6 Feb 2007, David Woodhouse wrote:
> >
> > Really, if our config is set up in sensible submenus (as in general it
> > _is_), the "see everything" behaviour really isn't bad.
>
> There are two fundamental problems with that statement:
>
> - no, it really isn't always
>
> Quite often, our Kconfig files have dependencies that are about where
> the *code* exists, rather than about some nice hierarchical system.
>
> Think of it this way: would you use a programming language that didn't
> allow you anything but totally hierarcical language constructs? No sane
> person would - because real life isn't hierarchical. Yes, there are
> many things that are, but not all things are.
>
> Example: many cryptographic algorithms are in crypto/. But then a lot
> of them ARE NOT. They are in arch/so-and-so/crypto/ or similar. Notice?
>
> NOT HIERARCHICAL.

It isn't that far off, and we could improve it if we wanted to. In
_general_ it's quite good already.

> - I don't use menus at all. I use the good old textual "make oldconfig".
> Trust me, I _want_ those irrelevant questions gone. They aren't "grayed
> out".
>
> So you seem to have this *wish* that real life was different than it is.
> But we aren't hierarchical, and even if we were, it *still* wouldn't work
> the way you want things to work.

It would work quite nicely in the graphical tools, although you've
thrown me a little by wanting it in the hacker's tool 'oldconfig' too.
You obviously care more about turning stuff _on_ with 'make oldconfig'
while other people who've spoken up seem to care more, as I do, about
turning stuff _off_ that way. If I want my hand held, I'm happy enough
to use the graphical tools.

I think the answer is probably just to go ahead and implement the 'make
oldconfig_noselect' so we can all have what we want.

--
dwmw2

2007-02-07 00:21:46

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Wed, 7 Feb 2007, David Woodhouse wrote:
>
> It isn't that far off, and we could improve it if we wanted to. In
> _general_ it's quite good already.

I agree that it's close to hierarchical. But it's literally the exceptions
that get you.

Let me mention (again) USB_STORAGE and ATA.

They are not "under" SCSI. Making them do that would be insane.

But yes, you can do hierarchies by adding "pseudo-variables": as
mentioned several times, we could actually split CONFIG_SCSI into two
separate ones: CONFIG_SCSI that selects the core infrastructure, and
CONFIG_SCSI_DRIVER that actually controls the "hierarchical visibility".

Then CONFIG_SCSI_DRIVER (and USB_STORAGE, and SATA) would just do a simple
'select SCSI'. It would _not_ be hierarchical, and it would very much use
that same old "select", but it would possibly be a cleanup at least in the
sense that now CONFIG_SCSI wouldn't be used two different ways (one to
hide most SCSI drivers, and one to enable the core SCSI infrastructure
code).

> It would work quite nicely in the graphical tools, although you've
> thrown me a little by wanting it in the hacker's tool 'oldconfig' too.
> You obviously care more about turning stuff _on_ with 'make oldconfig'
> while other people who've spoken up seem to care more, as I do, about
> turning stuff _off_ that way. If I want my hand held, I'm happy enough
> to use the graphical tools.

I tend to just edit the .config file, and run "make oldconfig". And I know
I'm not the only one, because I've talked to others who do the same.

And yes, then it's almost always correct to "turn things on as needed to
make everything work out right", while turning things off would be
actively wrong.

Linus

2007-02-07 00:35:53

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

Linus Torvalds wrote:
>
> On Wed, 7 Feb 2007, David Woodhouse wrote:
>> It isn't that far off, and we could improve it if we wanted to. In
>> _general_ it's quite good already.
>
> I agree that it's close to hierarchical. But it's literally the exceptions
> that get you.
>
> Let me mention (again) USB_STORAGE and ATA.
>
> They are not "under" SCSI. Making them do that would be insane.
>
> But yes, you can do hierarchies by adding "pseudo-variables": as
> mentioned several times, we could actually split CONFIG_SCSI into two
> separate ones: CONFIG_SCSI that selects the core infrastructure, and
> CONFIG_SCSI_DRIVER that actually controls the "hierarchical visibility".
>
> Then CONFIG_SCSI_DRIVER (and USB_STORAGE, and SATA) would just do a simple
> 'select SCSI'. It would _not_ be hierarchical, and it would very much use
> that same old "select", but it would possibly be a cleanup at least in the
> sense that now CONFIG_SCSI wouldn't be used two different ways (one to
> hide most SCSI drivers, and one to enable the core SCSI infrastructure
> code).
>
>> It would work quite nicely in the graphical tools, although you've
>> thrown me a little by wanting it in the hacker's tool 'oldconfig' too.
>> You obviously care more about turning stuff _on_ with 'make oldconfig'
>> while other people who've spoken up seem to care more, as I do, about
>> turning stuff _off_ that way. If I want my hand held, I'm happy enough
>> to use the graphical tools.
>
> I tend to just edit the .config file, and run "make oldconfig". And I know
> I'm not the only one, because I've talked to others who do the same.
>
> And yes, then it's almost always correct to "turn things on as needed to
> make everything work out right", while turning things off would be
> actively wrong.

That seems odd to me. I usually use edit + oldconfig to disable a
symbol. Maybe to enable a symbol occasionally. But the symbols
that I want to enable usually aren't listed in .config at all,
so I end up using another config tool to enable them.
E.g., a sound driver when SOUND is completely disabled.

--
~Randy

2007-02-07 00:38:08

[permalink] [raw]

Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

On Tue, 2007-02-06 at 16:21 -0800, Linus Torvalds wrote:
>
> On Wed, 7 Feb 2007, David Woodhouse wrote:
> >
> > It isn't that far off, and we could improve it if we wanted to. In
> > _general_ it's quite good already.
>
> I agree that it's close to hierarchical. But it's literally the exceptions
> that get you.
>
> Let me mention (again) USB_STORAGE and ATA.
>
> They are not "under" SCSI. Making them do that would be insane.

But in the graphical tool that's _good_. Because those are the options
you _wanted_ to see.

You don't want to go digging around under the SCSI menu where all those
boring hostadapters are, but you _do_ get to see the USB and ATA stuff
elsewhere.

But that's only for the graphical tool, which is where I actually
expected the handholding to be required. If you want it in 'oldconfig'
then I think that's weird, but I don't have a better solution than
'select', unfortunately.

> > It would work quite nicely in the graphical tools, although you've
> > thrown me a little by wanting it in the hacker's tool 'oldconfig' too.
> > You obviously care more about turning stuff _on_ with 'make oldconfig'
> > while other people who've spoken up seem to care more, as I do, about
> > turning stuff _off_ that way. If I want my hand held, I'm happy enough
> > to use the graphical tools.
>
> I tend to just edit the .config file, and run "make oldconfig". And I know
> I'm not the only one, because I've talked to others who do the same.

That's exactly what I do too.

> And yes, then it's almost always correct to "turn things on as needed to
> make everything work out right", while turning things off would be
> actively wrong.

My experience is exactly the opposite; perhaps because I spend so much
of my time working on the Fedora kernel where almost everything starts
off enabled by default, and I only ever want to turn stuff off.

I think 'make oldconfig_noselect' is the way forward. We can both have
what we want.

--
dwmw2

2007-02-07 02:09:30