linux-kernel - Re: Kconfig 'depend' vs. 'select'

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 27 Apr 2008 23:40:58 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	arjan@...radead.org
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Kconfig 'depend' vs. 'select'

From: Arjan van de Ven <arjan@...radead.org>
Date: Sun, 27 Apr 2008 21:58:40 -0700

> how far would "if you DEPENDS on FOO, and FOO is =m, you can only be
> =m or =n" get us?  or are there hidden traps on this?  (the hard
> case is if a non-tristate DEPENDS on a tristate, but... that's a
> trap anyway)

We want to avoid the problem of users having to sift through the dependency
chain just to figure something like that out.

It's rediculious to require a user to know if the obscure LEDS
subsystem is already set modular or not, for some unrelated reason, in
order to figure out how to build the wireless driver they want
statically into the kernel.

The whole idea behind my suggestion is that the user doesn't have
to know any of this implementation crap.  They just say "I want
wireless, and I want wireless driver X built statically into my
kernel, I don't care how you do it."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/