let W1 select NET

W1=y and Net=n fails with the following compile error:

<-- snip -->

...
LD .tmp_vmlinux1
drivers/built-in.o(.text+0x5efa38): In function `w1_alloc_dev':
: undefined reference to netlink_kernel_create' drivers/built-in.o(.text+0x5efac1): In function w1_alloc_dev':
: undefined reference to sock_release' drivers/built-in.o(.text+0x5efb31): In function w1_free_dev':
: undefined reference to sock_release' drivers/built-in.o(.text+0x5f0014): In function w1_netlink_send':
: undefined reference to alloc_skb' drivers/built-in.o(.text+0x5f00cd): In function w1_netlink_send':
: undefined reference to netlink_broadcast' drivers/built-in.o(.text+0x5f0131): In function w1_netlink_send':
: undefined reference to `skb_over_panic'
make: *** [.tmp_vmlinux1] Error 1

<-- snip -->

The patch below fixes this issue by letting W1 select NET.

@@ -2,6 +2,7 @@
 
 config W1
 	tristate "Dallas's 1-wire support"
+	select NET
 	---help---
 	  Dallas's 1-wire bus is usefull to connect slow 1-pin devices 
 	  such as iButtons and thermal sensors.

Sure.
W1 requires netlink and thus CONFIG_NET.

Thank you.
I've applied your patch to my tree
and will send it to GregKH -> Andrew Morton.

	Evgeniy Polyakov ( s0mbre )

Crash is better than data corruption. -- Art Grabowski

Hi,

W1 requires NET, and thus depends on it.
If you _do_ want W1 then you _do_ need network and then NET must be selected.

	Evgeniy Polyakov ( s0mbre )

Crash is better than data corruption. -- Art Grabowski

Hi,

A simple "depends on NET" does this as well, I see no reason to abuse select.

bye, Roman

In the case of NET the discussion is mostly hypothetically since nearly everyone has enabled NET.

But the similar case of USB_STORAGE selecting SCSI is an example where select is a big user-visible improvement over depends.

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Especially in the case where it is unlikely that somebody is deselecting NET, it makes more sense to depend on it, since IFF somebody deselects NET (i.e. embedding) he wants to actually see which drivers are still available (and she does not expect to see stil network drivers which reverse her selection).

Greetings
Bernd

eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

Hi,

comment "USB storage requires SCSI"
depends on SCSI=n

That's also user visible and doesn't confuse the user later, why he can't deselect SCSI.

Abusing select is really the wrong answer. What is needed is an improved user interface, which allows to search through the kconfig information or even can match hardware information to a driver and aids the user in selecting the required dependencies.
Keeping the kconfig database clean and making kernel configuration easier are really two separate problems and we shouldn't sacrifice the former for the latter.

bye, Roman

Hi Roman,

that's exactly what we have in 2.4, and it's definitely worse that the select.

Currently there's no better choice then "abusing select".

As soon as your improved user interface is included, I'm willing to help to evaluate which select's should be turned back into dependencies.

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

On Fri, 13 Aug 2004 14:11:28 +0200 (CEST) Roman Zippel wrote:

| Hi,
| 
| On Fri, 13 Aug 2004, Adrian Bunk wrote:
| 
| > But the similar case of USB_STORAGE selecting SCSI is an example where 
| > select is a big user-visible improvement over depends.
| 
| comment "USB storage requires SCSI"
| 	depends on SCSI=n
| 
| That's also user visible and doesn't confuse the user later, why he can't 
| deselect SCSI.

User-visible in xconfig (and gconfig?). Not in menuconfig, right? Maybe menuconfig's Help could also display dependency info...

| Abusing select is really the wrong answer. What is needed is an improved 
| user interface, which allows to search through the kconfig information or 
| even can match hardware information to a driver and aids the user in 
| selecting the required dependencies.

Nice idea. So are there places where SELECT is the right thing to do, i.e., it's required? (examples, please)

| Keeping the kconfig database clean and making kernel configuration easier 
| are really two separate problems and we shouldn't sacrifice the former for 
| the latter.

--
~Randy

Hi,

Select should be used for utility functions like CRC32, which often don't need their own prompt (except where some external module might need it, and a "default m" might suffice here).

bye, Roman

In which case, can we remove the user-visibility of CONFIG_NET and instead make all the protocols automatically select it.

I find the over-use of "select" distasteful, and produces a counter- intuitive configuration system. I'll carry on complaining each time I see a patch on LKML which introduces yet another over-use of this feature without properly considering the consequences of doing so.

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

That would kind of annoying for cases where one really does want to disable it though. A very nice property of the current system is that when one disables something like _NET, it removes a vast swath of other options (which removes a lot of clutter from the interface), and _know_ you won't inadvertently drag in _NET by enabling something.

Conversely, the requirement that _NET be enabled to select various network-related things isn't a problem from a user-interface point of view, as it's `obvious' that one needs a network to use them (and the config option to turn networking on is pretty starkly obvious when all other networking options are removed).

This latter point in particular doesn't hold for some other relationships (e.g. I seem to recall that various feature require SCSI somewhat counter-intuitively, as they're not inherently related to it, but rather have an implementation dependency on the kernel SCSI infrastructure).

-Miles

Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

I think it does it in reverse order:
if we have NET then we _may_ select W1, but if we _need_ W1 and do not know upon what it depends?

	Evgeniy Polyakov ( s0mbre )

Crash is better than data corruption. -- Art Grabowski

Hi Roman,

it's common practice to make it easier for people configuring the kernel to use select instead of depends in such cases.

It's also relatively safe since NET itself doesn't has any dependencies.

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Hi,

select is the wrong tool for this. NET is usually enabled anyway, selecting it has no real advantage.
Please use normal dependency whereever possible and use select in such cases only as exception and with very good reason. Making kernel configuration easier for aunt Tillie is not such reason.

bye, Roman

Otherwise, this would be problematic. Consider the following:

config FOO
bool "foo"
select BAR

config BAR
bool
depends on BAZ

config BAZ
bool
default n

You can select FOO, which will select BAR. In your config, you'll end up with CONFIG_FOO=y
CONFIG_BAR=y
# CONFIG_BAZ is not set

(similar result if you don't specify BAZ at all), which would get you into trouble. (I saw this while looking into what happens if s390 uses drivers/Kconfig, and got a headache why some stuff was selected by allyesconfig that depended on pci).

Question: Is this a bug or a feature? If the latter, select should probably not be used on anything that has dependencies...

Regards,
Cornelia

It is just not a good example.
In other words - it is bad config dependencies.
You just caught error.
Not very good example with depends:

config A
depends on B
config B
depends on C
config C
depends on A

Just do not create wrong dependencies - although it sounds like "do not create deadlocks".

	Evgeniy Polyakov ( s0mbre )

Crash is better than data corruption. -- Art Grabowski

Hm, none too easy with configurations spread over multiple files :) - however, should select really be able to activate an option with unmet dependencies?

(and iirc, you are warned about circular dependencies?)

Regards,
Cornelia

We have spinlock debugging, probably we need it in config parser too. I think it is better to fix such bugs( or features), then hide them with depend/select.

I'm sure noone depends on w1 :)

Evgeniy Polyakov ( s0mbre )

Only failure makes us experts. -- Theo de Raadt