From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Randy Dunlap <rdunlap@xenotime.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Linus <torvalds@linux-foundation.org>,
linux-crypto@vger.kernel.org
Subject: Re: linux-next: Tree for Oct 25 (crypto)
Date: Wed, 26 Oct 2011 19:15:17 +0200 [thread overview]
Message-ID: <20111026191517.71f3aa93@stein> (raw)
In-Reply-To: <4EA8350D.1080003@xenotime.net>
On Oct 26 Randy Dunlap wrote:
> On 10/26/11 05:33, Stefan Richter wrote:
> > On Oct 26 Herbert Xu wrote:
> >> --- a/crypto/Kconfig
> >> +++ b/crypto/Kconfig
> >> @@ -103,6 +103,7 @@ config CRYPTO_MANAGER2
> >> config CRYPTO_USER
> >> tristate "Userspace cryptographic algorithm configuration"
> >> select CRYPTO_MANAGER
> >> + select NET
> >> help
> >> Userapace configuration for cryptographic instantiations such as
btw, typo: "Userspace"
> >> cbc(aes).
> >>
> >> Cheers,
> >
> > If you do it this way, you also need to select everything on which NET
> > depends on. In v3.1, that would be (only) NLATTR which in turn does not
> > depend on anything else.
[...]
> That's correct, but it's better not to "select" an entire subsystem
> like NET at all.
I agree; I add to my comment the implication that --- as a rule of thumb
--- "select" should be avoided if the option to be selected has further
dependencies.
A downside of "config A\n depends on B" is of course that potential users
of option A who are unaware of option B or not interested in B may miss how
to enable A. Sometimes, a comment in the Kconfig file can help then.
Example (from linux-2.6.36/drivers/ieee1394/):
comment "PCILynx controller requires I2C"
depends on IEEE1394 && I2C=n
config IEEE1394_PCILYNX
tristate "PCILynx controller"
depends on PCI && IEEE1394 && I2C
select I2C_ALGOBIT
help
Say Y here if you have an IEEE-1394 controller with the Texas
Instruments PCILynx chip.
--
Stefan Richter
-=====-==-== =-=- ==-=-
http://arcgraph.de/sr/
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Randy Dunlap <rdunlap@xenotime.net>
Cc: Herbert Xu <herbert@gondor.hengli.com.au>,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Linus <torvalds@linux-foundation.org>,
linux-crypto@vger.kernel.org
Subject: Re: linux-next: Tree for Oct 25 (crypto)
Date: Wed, 26 Oct 2011 19:15:17 +0200 [thread overview]
Message-ID: <20111026191517.71f3aa93@stein> (raw)
In-Reply-To: <4EA8350D.1080003@xenotime.net>
On Oct 26 Randy Dunlap wrote:
> On 10/26/11 05:33, Stefan Richter wrote:
> > On Oct 26 Herbert Xu wrote:
> >> --- a/crypto/Kconfig
> >> +++ b/crypto/Kconfig
> >> @@ -103,6 +103,7 @@ config CRYPTO_MANAGER2
> >> config CRYPTO_USER
> >> tristate "Userspace cryptographic algorithm configuration"
> >> select CRYPTO_MANAGER
> >> + select NET
> >> help
> >> Userapace configuration for cryptographic instantiations such as
btw, typo: "Userspace"
> >> cbc(aes).
> >>
> >> Cheers,
> >
> > If you do it this way, you also need to select everything on which NET
> > depends on. In v3.1, that would be (only) NLATTR which in turn does not
> > depend on anything else.
[...]
> That's correct, but it's better not to "select" an entire subsystem
> like NET at all.
I agree; I add to my comment the implication that --- as a rule of thumb
--- "select" should be avoided if the option to be selected has further
dependencies.
A downside of "config A\n depends on B" is of course that potential users
of option A who are unaware of option B or not interested in B may miss how
to enable A. Sometimes, a comment in the Kconfig file can help then.
Example (from linux-2.6.36/drivers/ieee1394/):
comment "PCILynx controller requires I2C"
depends on IEEE1394 && I2C=n
config IEEE1394_PCILYNX
tristate "PCILynx controller"
depends on PCI && IEEE1394 && I2C
select I2C_ALGOBIT
help
Say Y here if you have an IEEE-1394 controller with the Texas
Instruments PCILynx chip.
--
Stefan Richter
-=====-==-== =-=- ==-=-
http://arcgraph.de/sr/
next prev parent reply other threads:[~2011-10-26 17:15 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-25 9:36 linux-next: Tree for Oct 25 Stephen Rothwell
2011-10-25 9:43 ` Stephen Rothwell
2011-10-25 10:42 ` Stephen Rothwell
2011-10-26 0:34 ` linux-next: Tree for Oct 25 (agp/intel-gtt.c) Randy Dunlap
2011-11-03 21:21 ` Randy Dunlap
2011-10-26 0:42 ` linux-next: Tree for Oct 25 (crypto) Randy Dunlap
2011-10-26 0:42 ` Randy Dunlap
2011-10-26 6:27 ` Herbert Xu
2011-10-26 6:27 ` Herbert Xu
2011-10-26 12:33 ` Stefan Richter
2011-10-26 12:33 ` Stefan Richter
2011-10-26 16:27 ` Randy Dunlap
2011-10-26 16:27 ` Randy Dunlap
2011-10-26 17:15 ` Stefan Richter [this message]
2011-10-26 17:15 ` Stefan Richter
2011-10-27 7:05 ` Valdis.Kletnieks
2011-10-27 7:45 ` Herbert Xu
2011-10-27 7:45 ` Herbert Xu
2011-10-29 23:20 ` Valdis.Kletnieks
2011-10-26 18:26 ` linux-next: Tree for Oct 25 (mfd/ab8500) Randy Dunlap
2011-10-30 23:04 ` Samuel Ortiz
2011-10-26 18:37 ` linux-next: Tree for Oct 25 (pci/ats.c) Randy Dunlap
2011-11-10 13:09 ` Ingo Molnar
2011-10-26 18:39 ` linux-next: Tree for Oct 25 (target) Randy Dunlap
2011-10-26 19:53 ` Nicholas A. Bellinger
2011-10-26 20:40 ` Stephen Rothwell
2011-10-26 20:42 ` Nicholas A. Bellinger
2011-10-26 18:47 ` linux-next: Tree for Oct 25 (sb_edac.c) Randy Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111026191517.71f3aa93@stein \
--to=stefanr@s5r6.in-berlin.de \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=rdunlap@xenotime.net \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.