Super Kernel Sunday!

Super Kernel Sunday!

[Linus Torvalds]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5611 bytes --]


In a widely anticipated move, Linux "headcase" Torvalds today announced
the immediate availability of the most advanced Linux kernel to date,
version 2.6.20.

Before downloading the actual new kernel, most avid kernel hackers have
been involved in a 2-hour pre-kernel-compilation count-down, with some
even spending the preceding week doing typing exercises and reciting PI
to a thousand decimal places.

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. 

As ICD head analyst Walter Dickweed put it: "Releasing a new kernel on
Superbowl Sunday means that the important 'pasty white nerd'
constituency finally has something to do while the rest of the country
sits comatose in front of their 65" plasma screens". 

Walter was immediately attacked for his racist and insensitive remarks
by Geeks without Borders representative Marilyn vos Savant, who pointed
out that not all of their members are either pasty nor white.  "Some of
them even shower!" she added, claiming that the constant stereotyping
hurts nerds' standing in society. 

Geeks outside the US were just confused about the whole issue, and were
heard wondering what the big hoopla was all about. Some of the more
culturally aware of them were heard snickering about balls that weren't
even round.

                      Linus

---

Shortlog since 2.6.20-rc7. Fixes, fixes.

There's a full ChangeLog together with the tar-ball and patches, but let 
me just summarize it as: "A lot of stuff. All over. And KVM."

I tried rather hard to make 2.6.20 largely a "stabilization release". 
Unlike a lot of kernels lately, there aren't really any big fundamental 
changes to some core infrastructure area, and while we always have bugs, I 
really am hoping that we fixed many more than we introduced. 

Have fun. And remember: the thousandth decimal is, of course, 9. There 
*will* be a test on this afterwards.


Adrian Bunk (1):
      [NETFILTER]: nf_conntrack_h323: fix compile error with CONFIG_IPV6=m, CONFIG_NF_CONNTRACK_H323=y

Al Viro (12):
      netxen patches
      fix frv headers_check
      mca_nmi_hook() can be called at any point
      ide section fixes
      endianness bug: ntohl() misspelled as >> 24 in fh_verify().
      fork_idle() should be __cpuinit, not __devinit
      __crc_... is intended to be absolute
      efi_set_rtc_mmss() is not __init
      sanitize sections for sparc32 smp
      radio modems sitting on serial port are not for s390
      uml-i386: fix build breakage with CONFIG_HIGHMEM
      fix rtl8150

Alan (3):
      pata_atiixp: propogate cable detection hack from drivers/ide to the new driver
      pata_via: Correct missing comments
      libata: Fix ata_busy_wait() kernel docs

Andrew Morton (2):
      pci: remove warning messages
      revert blockdev direct io back to 2.6.19 version

Auke Kok (1):
      e100: fix napi ifdefs removing needed code

Avi Kivity (1):
      KVM: fix lockup on 32-bit intel hosts with nx disabled in the bios

Bartlomiej Zolnierkiewicz (1):
      via82cxxx: fix typo ("cx7000" should be corrected to "cx700")

Bob Breuer (1):
      [SPARC32]: Fix over-optimization by GCC near ip_fast_csum.

Brian King (1):
      libata: Initialize nbytes for internal sg commands

David C Somayajulu (1):
      [SCSI] qla4xxx: bug fixes

Evgeniy Dushistov (1):
      MAINTAINERS: ufs entry

Frédéric Riss (1):
      EFI x86: pass firmware call parameters on the stack

Guillaume Chazarain (1):
      procfs: Fix listing of /proc/NOT_A_TGID/task

Haavard Skinnemoen (1):
      Remove avr32@atmel.com from MAINTAINERS

Jean Delvare (1):
      via quirk update

Jeff Garzik (1):
      x86-64: define dma noncoherent API functions

Jens Osterkamp (1):
      spidernet : fix memory leak in spider_net_stop

John Keller (1):
      Altix: more ACPI PRT support

Kai Makisara (1):
      [SCSI] st: A MTIOCTOP/MTWEOF within the early warning will cause the file number to be incorrect

Ken Chen (1):
      aio: fix buggy put_ioctx call in aio_complete - v2

Lars Immisch (1):
      [NETFILTER]: SIP conntrack: fix skipping over user info in SIP headers

Li Yewang (1):
      [IPV6]: fix BUG of ndisc_send_redirect()

Linus Torvalds (3):
      Revert "[PATCH] mm: micro optimise zone_watermark_ok"
      Revert "[PATCH] fix typo in geode_configre()@cyrix.c"
      Linux 2.6.20

Magnus Damm (1):
      kexec: Avoid migration of already disabled irqs (ia64)

Matthew Wilcox (1):
      [SCSI] Fix scsi_add_device() for async scanning

Michael Chan (1):
      [BNX2]: PHY workaround for 5709 A0.

Mike Frysinger (1):
      alpha: fix epoll syscall enumerations

Nagendra Singh Tomar (1):
      [SCSI] sd: udev accessing an uninitialized scsi_disk field results in a crash

Neil Horman (1):
      [IPV6]: Fix up some CONFIG typos

Patrick McHardy (5):
      [NETFILTER]: xt_connbytes: fix division by zero
      [NETFILTER]: SIP conntrack: fix out of bounds memory access
      [NETFILTER]: xt_hashlimit: fix ip6tables dependency
      [NET_SCHED]: act_ipt: fix regression in ipt action
      [NETFILTER]: ctnetlink: fix compile failure with NF_CONNTRACK_MARK=n

Peter Korsgaard (1):
      net/smc911x: match up spin lock/unlock

Randy Dunlap (2):
      [MAINTAINERS]: netfilter@ is subscribers-only
      sysrq: showBlockedTasks is sysrq-W

Tejun Heo (1):
      ahci/pata_jmicron: fix JMicron quirk

Vlad Yasevich (1):
      [SCTP]: Force update of the rto when processing HB-ACK

Re: Super Kernel Sunday!

[Bauke Jan Douma]

Linus Torvalds wrote on 04-02-07 20:10:

Walter Dickweed I know, but who is this Superbowl Sunday?

bjd

Re: Super Kernel Sunday!

[Alessandro Suardi]

On 2/4/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> In a widely anticipated move, Linux "headcase" Torvalds today announced
> the immediate availability of the most advanced Linux kernel to date,
> version 2.6.20.
>
> Before downloading the actual new kernel, most avid kernel hackers have
> been involved in a 2-hour pre-kernel-compilation count-down, with some
> even spending the preceding week doing typing exercises and reciting PI
> to a thousand decimal places.
>
> 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.
>
> As ICD head analyst Walter Dickweed put it: "Releasing a new kernel on
> Superbowl Sunday means that the important 'pasty white nerd'
> constituency finally has something to do while the rest of the country
> sits comatose in front of their 65" plasma screens".
>
> Walter was immediately attacked for his racist and insensitive remarks
> by Geeks without Borders representative Marilyn vos Savant, who pointed
> out that not all of their members are either pasty nor white.  "Some of
> them even shower!" she added, claiming that the constant stereotyping
> hurts nerds' standing in society.
>
> Geeks outside the US were just confused about the whole issue, and were
> heard wondering what the big hoopla was all about. Some of the more
> culturally aware of them were heard snickering about balls that weren't
> even round.

Ha. And you wouldn't have thought there was someone who

 - was born and raised and lives in old europe
 - builds and tests 100+ kernels a year
 - has already built 2.6.20

[asuardi@sandman ~]$ cat /proc/version
Linux version 2.6.20 (asuardi@sandman) (gcc version 4.1.1 20070105
(Red Hat 4.1.1-51)) #1 Sun Feb 4 20:41:13 CET 2007

...because...

there's the SUPERBOWL to watch in front of a 32" LCD screen !!

 (yes, I took tomorrow off work of course ;)

--alessandro

 "but I thought that I should let you know
  the things that I don't always show
  might not be worth the time it took"

     (Steve Wynn, 'If My Life Was An Open Book')

Re: Super Kernel Sunday!

[Gene Heskett]

On Sunday 04 February 2007 14:40, Bauke Jan Douma wrote:
>Linus Torvalds wrote on 04-02-07 20:10:
>
>Walter Dickweed I know, but who is this Superbowl Sunday?
>
>bjd

See what Linus meant, folks?  Chuckle...

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.

Re: Super Kernel Sunday!

[Kevin K]

On Feb 4, 2007, at 1:40 PM, Bauke Jan Douma wrote:

> Linus Torvalds wrote on 04-02-07 20:10:
>
> Walter Dickweed I know, but who is this Superbowl Sunday?
>
> bjd

Doesn't it have something to do with the World Series or World Cup?

Re: Super Kernel Sunday!

[Jonathan Sambrook]

Linus Torvalds wrote:

> Geeks outside the US were just confused about the whole issue, and were
> heard wondering what the big hoopla was all about. Some of the more
> culturally aware of them were heard snickering about balls that weren't
> even round.

Ah, they're playing rugby. Funny, must be the Seven Nations Championship [1] now, and I'd not noticed.

Eeep eep,
Jonathan


[1] http://en.wikipedia.org/wiki/Six_Nations_Championship

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

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> 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 <mingo@elte.hu>

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 <mingo@elte.hu>
---
 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

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

[Josh Boyer]

On 2/5/07, Ingo Molnar <mingo@elte.hu> wrote:
> Subject: [patch] MTD: fix DOC2000/2001/2001PLUS build error
> From: Ingo Molnar <mingo@elte.hu>
>
> 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

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

[David Woodhouse]

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

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

[Ingo Molnar]

* David Woodhouse <dwmw2@infradead.org> 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

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

[Arjan van de Ven]

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

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

[Russell King]

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:

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

[Ingo Molnar]

* Russell King <rmk+lkml@arm.linux.org.uk> 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

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

[David Woodhouse]

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

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

[Ingo Molnar]

* David Woodhouse <dwmw2@infradead.org> 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

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

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> 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

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

[Linus Torvalds]

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

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

[David Woodhouse]

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

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

[Russell King]

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:

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

[Russell King]

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:

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

[David Woodhouse]

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

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

[Ingo Molnar]

* Russell King <rmk+lkml@arm.linux.org.uk> 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

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

[Linus Torvalds]

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

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

[Russell King]

On Mon, Feb 05, 2007 at 05:52:33PM +0100, Ingo Molnar wrote:
> 
> * Russell King <rmk+lkml@arm.linux.org.uk> 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:

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

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> 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

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

[Russell King]

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:

Re: Super Kernel Sunday!

[Jan Engelhardt]

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/

Re: Super Kernel Sunday!

[Kevin Fox]

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

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

[Ingo Oeser]

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

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

[David Woodhouse]

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

[2.6.20] Regression in dmfe driver

[Thomas Bächler]

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.

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

[Linus Torvalds]

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

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

[David Woodhouse]

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

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

[David Woodhouse]

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

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

[Linus Torvalds]

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

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

[Alan]

> 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

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

[David Woodhouse]

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

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

[Alan]

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

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

[Linus Torvalds]

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

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

[Randy Dunlap]

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

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

[Linus Torvalds]

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

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

[Linus Torvalds]

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

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

[David Woodhouse]

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

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

[Linus Torvalds]

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

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

[Jeff Garzik]

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

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

[Mark Rustad]

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, MRustad@gmail.com

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

[Theodore Tso]

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

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

[Matt Mackall]

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.

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

[Matt Mackall]

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.

Re: [2.6.20] Regression in dmfe driver

[Thierry Vignaud]

Thomas Bächler <thomas@archlinux.org> 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).

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

[David Woodhouse]

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

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

[Gerhard Mack]

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

gmack@innerfire.net

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

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

[Jörn Engel]

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

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

[Mark Lord]

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

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

[Paul Mundt]

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.

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

[Bill Davidsen]

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 <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

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

[Bill Davidsen]

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 <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

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

[Bill Davidsen]

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 <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

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

[Bill Davidsen]

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 <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

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

[Mark Rustad]

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, MRustad@gmail.com

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

[Matt Mackall]

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.

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

[Linus Torvalds]

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

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

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: Super Kernel Sunday!

[Stephen Hemminger]

On Mon, 5 Feb 2007 18:58:39 +0100 (MET)
Jan Engelhardt <jengelh@linux01.gwdg.de> 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 <shemminger@linux-foundation.org>

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

[David Woodhouse]

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

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

[Haavard Skinnemoen]

On 2/6/07, Matt Mackall <mpm@selenic.com> 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

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

[Randy Dunlap]

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

Re: [2.6.20] Regression in dmfe driver

[Thomas Bächler]

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?

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

[Linus Torvalds]

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

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

[Linus Torvalds]

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

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

[Linus Torvalds]

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

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

[David Woodhouse]

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

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

[Linus Torvalds]

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

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

[David Woodhouse]

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

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

[Linus Torvalds]

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

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

[David Woodhouse]

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

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

[Randy Dunlap]

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

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

[David Woodhouse]

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

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

[Linus Torvalds]

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

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

[Robert P. J. Day]

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

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

[Linus Torvalds]

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

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

[David Woodhouse]

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

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

[Linus Torvalds]

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

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

[Randy Dunlap]

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

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

[David Woodhouse]

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

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

[Linus Torvalds]

On Wed, 7 Feb 2007, David Woodhouse wrote:
> 
> I think 'make oldconfig_noselect' is the way forward. We can both have
> what we want.

Actually, I think there might be an even more interesting schenario.

The Kconfig language right not is ternary, which is fine as an arithmetic, 
but the problem *may* be that we actually want it to be more expressive.

If instead of a ternary "y/m/n" calculus, we would use a "Y/y/m/n/N" 
quinary logic, where "Y" and "N" are like "force on/off", you might have 
the following:

	"y + depends on => n"
	"Y + depends on => Y, and the depends on to Y too"
	"n/N + depends on => n"

	"y/Y + selected => y"
	"n + select => y"
	"N + select => N, and the select to N"

In other words, "Y" means "force to Y, even if it has a dependency (which 
we'll also have to force", while "N" means "force to N, even if it is 
getting selected, in which case the selection will also be forced to N").

So then you can say things like

 - edit .config, and set *any* value to "Y", and it will force-enable 
   anything that that depends on when you run "make oldconfig", even if it 
   was an "depends on"

 - edit .config, and set *any* value to "N", and it fill force-disable 
   anything that selects that when you you run "make oldconfig"

The problem here is that:

 - you can get inconsistent situations ("but he wanted to both force that 
   on *and* off!")

 - "select" actually is much nicer, in that it unambiguously selects one 
   other symbol. But "depends on" is very hard to force, because you may 
   have something like (totally made up)

	depends on X86 || (ALPHA && PCI)

   which is impossible to force (*which* one do you force?) on.

but something like this would be nice for both the text-based "make 
oldconfig" kind of thing *and* for any graphical configuration things 
("dammit, I want this OFF, when I press the force-off-buffon you turn 
anything off that needs it!")

But the two problems above might make it impractical..

			Linus

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

[Sunil Naidu]

On 2/7/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> 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.

I see a scenario (many others may have got this idea):-

Reading H/W config at the time of doing make (x)config. Idea is to
tell the user.....hey you have SATA disk, so you can't disable this!
(making life easier while compiling the kernel, kinda fast track auto
support)

Can we do this (some how by Kconfig) by reading from the device info
/etc/sysconfig/hwconf or any other way?

If we could do that like above, how to manage dynamic devices - say I
plug in a USB based Printer? Or a simple USB Thumb drive? Giving the
user "Optional Selection" settings from Kconfig? Say, after H/W auto
detection by Kconfig, hand over the user an option - "Buddy, do you
want to add any other device support into this kernel?"

Does this makes sense, Linus?

>
>                 Linus
>

~Akula2

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

[David Lang]

On Tue, 6 Feb 2007, Mark Lord wrote:

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

I've been compiling and deploying kernels since 0.99 days, and I still get bit 
by this sort of thing. This is one of the reasons why I've liked the minimal 
config option that Rob Landley has proposed a few times wher eyou specify the 
things that you need and let the build system put in the nessasary dependancies.

I started out useing menuconfig, used the TCL based xconfig, but went back to 
menuconfig when the new xconfig came out (I now do most of my kernel compiles on 
remote machines that I may or may not have X access to anyway)

especially if a particular driver/feature doesn't want to compile, tracking down 
how to turn it off can be a pain. The idea that Alan posted of saying 'disabling 
this function will disable the following things as well' would be an extremely 
useful enhancement.

I think that there are more of us out here that configure and compile kernels, 
but aren't kernel hackers then most people (especialy the distros) want to 
admit. (and for that matter, many of the distro support policies activly 
discourage people from telling the distro when they compile a kernel)

David Lang

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

[Jörn Engel]

On Tue, 6 February 2007 10:16:17 -0500, Mark Lord wrote:
> 
> That interface is driven entirely backwards.
> The funtionality option should always be visible,

You are absolutely correct.  The _interface_ is horrible.  And changing
the config language won't change that fact one bit.

Make *config is broken, not the Kconfig files underneith.

Jörn

-- 
Joern's library part 13:
http://www.chip-architect.com/

Re: [PATA] Failed to set xfermode on LITE-ON LTR-48246S

[Philipp Matthias Hahn]

Hello!

As reported by John Williams and others like in
http://www.mail-archive.com/linux-ide@vger.kernel.org/msg03088.html
I too have a problem with 2.6.20.1 using ata_piix not detecting the
CD-ROM any more. Applying the patch from
http://lkml.org/lkml/2007/2/12/24 did not help, but additionally
applying
http://readlist.com/lists/vger.kernel.org/linux-kernel/45/228948.html
made it work. Here's the relevant extra debugging output:

ata_piix 0000:00:1f.1: version 2.00ac7
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0x2800 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x2808 irq 15
scsi0 : ata_piix
ata1.00: ATA-7, max UDMA/133, 160086528 sectors: LBA
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/100
scsi1 : ata_piix
ata2.00: ATAPI, max UDMA/33
ata2: ata_altstatus take 4us
ata2.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access     ATA      Maxtor 6Y080L0   YAR4 PQ: 0 ANSI: 5
SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 > sda4
 sd 0:0:0:0: Attached scsi disk sda
 scsi 1:0:0:0: CD-ROM            LITE-ON  LTR-48246S       SID4 PQ: 0 ANSI: 5
 sr0: scsi3-mmc drive: 230x/48x writer cd/rw xa/form2 cdda tray
 Uniform CD-ROM driver Revision: 3.20
 sr 1:0:0:0: Attached scsi CD-ROM sr0

Something other I should try to get this fixed for 2.6.20.2+?

BYtE
Philipp
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn@titan.lahn.de

Re: [PATA] Failed to set xfermode on LITE-ON LTR-48246S

[Tejun Heo]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

Philipp Matthias Hahn wrote:
> Hello!
> 
> As reported by John Williams and others like in
> http://www.mail-archive.com/linux-ide@vger.kernel.org/msg03088.html
> I too have a problem with 2.6.20.1 using ata_piix not detecting the
> CD-ROM any more. Applying the patch from
> http://lkml.org/lkml/2007/2/12/24 did not help, but additionally
> applying
> http://readlist.com/lists/vger.kernel.org/linux-kernel/45/228948.html
> made it work. Here's the relevant extra debugging output:

* Did it work with previous kernels?

* Does applying the attached patch over unpatched 2.6.20.1 fix the problem?

-- 
tejun

[-- Attachment #2: ata_piix-polling-xfer.patch --]
[-- Type: text/x-patch, Size: 650 bytes --]

diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index dc42ba1..78e6ac5 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -105,8 +105,10 @@ enum {
 	PIIX_FLAG_AHCI		= (1 << 27), /* AHCI possible */
 	PIIX_FLAG_CHECKINTR	= (1 << 28), /* make sure PCI INTx enabled */
 
-	PIIX_PATA_FLAGS		= ATA_FLAG_SLAVE_POSS,
-	PIIX_SATA_FLAGS		= ATA_FLAG_SATA | PIIX_FLAG_CHECKINTR,
+	PIIX_PATA_FLAGS		= ATA_FLAG_SLAVE_POSS |
+				  ATA_FLAG_SETXFER_POLLING,
+	PIIX_SATA_FLAGS		= ATA_FLAG_SATA | PIIX_FLAG_CHECKINTR |
+				  ATA_FLAG_SETXFER_POLLING,
 
 	/* combined mode.  if set, PATA is channel 0.
 	 * if clear, PATA is channel 1.

Re: [PATA] Failed to set xfermode on LITE-ON LTR-48246S

[Philipp Matthias Hahn]

Helo Tejun!

On Mon, Mar 05, 2007 at 01:10:10PM +0900, Tejun Heo wrote:
> Philipp Matthias Hahn wrote:
> > As reported by John Williams and others like in
> > http://www.mail-archive.com/linux-ide@vger.kernel.org/msg03088.html
> > I too have a problem with 2.6.20.1 using ata_piix not detecting the
> > CD-ROM any more. Applying the patch from
> > http://lkml.org/lkml/2007/2/12/24 did not help, but additionally
> > applying
> > http://readlist.com/lists/vger.kernel.org/linux-kernel/45/228948.html
> > made it work. Here's the relevant extra debugging output:
> 
> * Did it work with previous kernels?

Previously I was using the old IDE modules just fine, it was only with
2.6.20 that I did the switch to libata and encountered the problem.

> * Does applying the attached patch over unpatched 2.6.20.1 fix the problem?

Yes, it seems to fix it. (testes on top of the first patch mentioned
above, but witheout the second one.).
If I should test it as the sole patche, just mail me again please.

BYtE
Philipp
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn@titan.lahn.de

Re: [PATA] Failed to set xfermode on LITE-ON LTR-48246S

[Tejun Heo]

Philipp Matthias Hahn wrote:
> On Mon, Mar 05, 2007 at 01:10:10PM +0900, Tejun Heo wrote:
>> Philipp Matthias Hahn wrote:
>>> As reported by John Williams and others like in
>>> http://www.mail-archive.com/linux-ide@vger.kernel.org/msg03088.html
>>> I too have a problem with 2.6.20.1 using ata_piix not detecting the
>>> CD-ROM any more. Applying the patch from
>>> http://lkml.org/lkml/2007/2/12/24 did not help, but additionally
>>> applying
>>> http://readlist.com/lists/vger.kernel.org/linux-kernel/45/228948.html
>>> made it work. Here's the relevant extra debugging output:
>> * Did it work with previous kernels?
> 
> Previously I was using the old IDE modules just fine, it was only with
> 2.6.20 that I did the switch to libata and encountered the problem.
> 
>> * Does applying the attached patch over unpatched 2.6.20.1 fix the problem?
> 
> Yes, it seems to fix it. (testes on top of the first patch mentioned
> above, but witheout the second one.).
> If I should test it as the sole patche, just mail me again please.

Yeap, please test it on top of vanilla kernel to verify that the patch
proper fixes the problem.

Thanks.

-- 
tejun

Re: [PATA] Failed to set xfermode on LITE-ON LTR-48246S

[Philipp Matthias Hahn]

Hello Tejun!

On Tue, Mar 06, 2007 at 12:46:07AM +0900, Tejun Heo wrote:
> Philipp Matthias Hahn wrote:
> > On Mon, Mar 05, 2007 at 01:10:10PM +0900, Tejun Heo wrote:
> > > * Does applying the attached patch over unpatched 2.6.20.1 fix the problem?
> >
> > Yes, it seems to fix it. (testes on top of the first patch mentioned
> > above, but witheout the second one.).
> > If I should test it as the sole patche, just mail me again please.
>
> Yeap, please test it on top of vanilla kernel to verify that the patch
> proper fixes the problem.

Yes, applying only this patch does fix the problem.
Thank you for your support.

BYtE
Philipp
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn@titan.lahn.de

Re: [PATA] Failed to set xfermode on LITE-ON LTR-48246S

[Tejun Heo]

Philipp Matthias Hahn wrote:
> Hello Tejun!
> 
> On Tue, Mar 06, 2007 at 12:46:07AM +0900, Tejun Heo wrote:
>> Philipp Matthias Hahn wrote:
>>> On Mon, Mar 05, 2007 at 01:10:10PM +0900, Tejun Heo wrote:
>>>> * Does applying the attached patch over unpatched 2.6.20.1 fix the problem?
>>> Yes, it seems to fix it. (testes on top of the first patch mentioned
>>> above, but witheout the second one.).
>>> If I should test it as the sole patche, just mail me again please.
>> Yeap, please test it on top of vanilla kernel to verify that the patch
>> proper fixes the problem.
> 
> Yes, applying only this patch does fix the problem.
> Thank you for your support.

Okay, it seems we'll have to default to polling SETXFER.  I'll forward
it upstream soon.  Thanks.

-- 
tejun