Some of the options that needlessly wrote in their help text which options they do select (patch already sent) didn't obey the most important rule of select If you select something, you have to ensur
akpm@xxxxxxxx wrote: From: Adrian Bunk <bunk@xxxxxxxxx> Some of the options that needlessly wrote in their help text which options they do select (patch already sent) didn't obey the most important r
As I already said, this implies that options like CRYPTO_AES and CRYPTO_MICHAEL_MIC can no longer depend on CRYPTO. It's possible to change the crypto options in a way that CRYPTO is selected as requ
Adrian Bunk wrote: On Fri, Mar 04, 2005 at 12:33:19PM -0500, Jeff Garzik wrote: akpm@xxxxxxxx wrote: From: Adrian Bunk <bunk@xxxxxxxxx> Some of the options that needlessly wrote in their help text wh
The way kconfig currently works, you have to ensure that the dependencies of what you select are fulfilled. And handling dependencies as select chains creates some subtle problems: Consider the follo
Yes Adrian's right. In the other places where we select CRYPTO symbols, we always make sure that CRYPTO itself is selected. See net/ipv4/Kconfig for example. Cheers, -- Visit Openswan at http://www.o
Herbert Xu wrote: On Sat, Mar 05, 2005 at 12:07:18AM +0100, Adrian Bunk wrote: The way kconfig currently works, you have to ensure that the dependencies of what you select are fulfilled. Yes Adrian's
I asked about the first example of my last email: What values of the variables A-E do you expect exactly if the user turns on F? If you expect this to work, which unambiguous solution do you propose
Adrian Bunk wrote: On Sun, Mar 06, 2005 at 01:00:50PM -0500, Jeff Garzik wrote: Herbert Xu wrote: On Sat, Mar 05, 2005 at 12:07:18AM +0100, Adrian Bunk wrote: The way kconfig currently works, you hav
That would be nice to have. However, until such a patch is integrated we need to write Kconfig entries that work properly. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{Pm
Herbert Xu wrote: On Sun, Mar 06, 2005 at 01:00:50PM -0500, Jeff Garzik wrote: I would rather fix Kconfig. If we are selecting X_1 -- which explicitly depends on X -- when Kconfig should automaticall
Some of the options that needlessly wrote in their help text which options they do select (patch already sent) didn't obey the most important rule of select If you select something, you have to ensur
Some of the options that needlessly wrote in their help text which options they do select (patch already sent) didn't obey the most important rule of select If you select something, you have to ensur
As I already said, this implies that options like CRYPTO_AES and CRYPTO_MICHAEL_MIC can no longer depend on CRYPTO. It's possible to change the crypto options in a way that CRYPTO is selected as requ
Some of the options that needlessly wrote in their help text which options they do select (patch already sent) didn't obey the most important rule of select If you select something, you have to ensur
The way kconfig currently works, you have to ensure that the dependencies of what you select are fulfilled. And handling dependencies as select chains creates some subtle problems: Consider the follo
Yes Adrian's right. In the other places where we select CRYPTO symbols, we always make sure that CRYPTO itself is selected. See net/ipv4/Kconfig for example. Cheers, -- Visit Openswan at http://www.o
The way kconfig currently works, you have to ensure that the dependencies of what you select are fulfilled. Yes Adrian's right. In the other places where we select CRYPTO symbols, we always make sure
I asked about the first example of my last email: What values of the variables A-E do you expect exactly if the user turns on F? If you expect this to work, which unambiguous solution do you propose
The way kconfig currently works, you have to ensure that the dependencies of what you select are fulfilled. Yes Adrian's right. In the other places where we select CRYPTO symbols, we always make sure