* Re: linux kernel development
From: Américo Wang @ 2011-08-22 4:53 UTC (permalink / raw)
To: Niloofar Fazlollahi; +Cc: netdev, linux-kernel, linux-next
In-Reply-To: <CAK8ka9wP_V7ngtR0jv7T3vNZoTep9c18=AgRSe9efYAyXejUPg@mail.gmail.com>
On Mon, Aug 22, 2011 at 12:51 PM, Niloofar Fazlollahi
<nfazlollahi@gmail.com> wrote:
> Hi,
>
> I have a generic question and appreciate your kind response.
>
> What is the process and requirements for getting the linux kernel community
>
> approval to commit a code into linux kernel (related to networking - TCP).
Hello,
Please read the documents in Documentation/development-process/ directory
of the kernel source code.
Thanks.
^ permalink raw reply
* Re: linux-next: manual merge of the pm tree with the s390 tree
From: Rafael J. Wysocki @ 2011-08-22 6:20 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Tejun Heo, Martin Schwidefsky,
Heiko Carstens
In-Reply-To: <20110822123705.d947c6a2548082168df9c86a@canb.auug.org.au>
On Monday, August 22, 2011, Stephen Rothwell wrote:
> Hi Rafael,
>
> Today's linux-next merge of the pm tree got a conflict in
> arch/s390/include/asm/thread_info.h between commit 5f67c275efe7 ("[S390]
> fix _TIF_SINGLE_STEP definition") from the s390 tree and commit
> c9ff4d7b50c4 ("freezer: remove now unused TIF_FREEZE") from the pm tree.
>
> I fixed it up (see below)
Thanks!
> and can carry the fix as necessary.
Please do that.
Rafael
^ permalink raw reply
* Re: [PATCH linux-next] mfd: omap-usb-host: add module.h and export.h to fix build break
From: Samuel Ortiz @ 2011-08-22 15:06 UTC (permalink / raw)
To: Anand Gadiyar; +Cc: linux-kernel, linux-next, Paul Gortmaker
In-Reply-To: <1313767445-20033-1-git-send-email-gadiyar@ti.com>
Hi Anand,
On Fri, Aug 19, 2011 at 08:54:05PM +0530, Anand Gadiyar wrote:
> linux-next as of 20110817 fails to build if these two headers
> are not included. Including module.h is sufficient for now,
> but add export.h for EXPORT_SYMBOL and THIS_MODULE in advance
> to avoid a later build break.
>
> Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
> Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
I applied a similar patch (without the +#include <linux/export.h>) from Ming
Lei <tom.leiming@gmail.com>.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: linux-next: Tree for Aug 22 (drivers/power/pda_power.c)
From: Randy Dunlap @ 2011-08-22 16:10 UTC (permalink / raw)
To: Stephen Rothwell, lud; +Cc: linux-next, LKML
In-Reply-To: <20110822145304.980529cb921e5f1321c622da@canb.auug.org.au>
On Mon, 22 Aug 2011 14:53:04 +1000 Stephen Rothwell wrote:
> Hi all,
>
> [The kernel.org mirroring is a bit low today]
When CONFIG_USB_OTG_UTILS is not enabled:
drivers/power/pda_power.c: In function 'pda_power_probe':
drivers/power/pda_power.c:322: error: 'otg_is_usb_online' undeclared (first use in this function)
drivers/power/pda_power.c:322: error: (Each undeclared identifier is reported only once
drivers/power/pda_power.c:322: error: for each function it appears in.)
drivers/power/pda_power.c:325: error: 'otg_is_ac_online' undeclared (first use in this function)
drivers/power/pda_power.c:371: error: 'otg_handle_notification' undeclared (first use in this function)
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* [PATCH -next] staging: fix comedi build when COMEDI_PCI is not enabled
From: Randy Dunlap @ 2011-08-22 18:13 UTC (permalink / raw)
To: Stephen Rothwell, driverdevel, akpm
Cc: linux-next, LKML, gregkh, an Abbott, ori Hess
In-Reply-To: <20110822145304.980529cb921e5f1321c622da@canb.auug.org.au>
From: Randy Dunlap <rdunlap@xenotime.net>
Fix build when CONFIG_ISA_DMA_API is enabled but
CONFIG_COMEDI_PCI[_DRIVERS] is not enabled.
Fixes these build errors:
drivers/staging/comedi/drivers/ni_labpc.c: In function 'labpc_ai_cmd':
drivers/staging/comedi/drivers/ni_labpc.c:1351: error: implicit declaration of function 'labpc_suggest_transfer_size'
drivers/staging/comedi/drivers/ni_labpc.c: At top level:
drivers/staging/comedi/drivers/ni_labpc.c:1802: error: conflicting types for 'labpc_suggest_transfer_size'
drivers/staging/comedi/drivers/ni_labpc.c:1351: note: previous implicit declaration of 'labpc_suggest_transfer_size' was here
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
drivers/staging/comedi/drivers/ni_labpc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- linux-next-20110822.orig/drivers/staging/comedi/drivers/ni_labpc.c
+++ linux-next-20110822/drivers/staging/comedi/drivers/ni_labpc.c
@@ -241,8 +241,10 @@ static int labpc_eeprom_write_insn(struc
struct comedi_insn *insn,
unsigned int *data);
static void labpc_adc_timing(struct comedi_device *dev, struct comedi_cmd *cmd);
-#ifdef CONFIG_COMEDI_PCI
+#ifdef CONFIG_ISA_DMA_API
static unsigned int labpc_suggest_transfer_size(struct comedi_cmd cmd);
+#endif
+#ifdef CONFIG_COMEDI_PCI
static int labpc_find_device(struct comedi_device *dev, int bus, int slot);
#endif
static int labpc_dio_mem_callback(int dir, int port, int data,
^ permalink raw reply
* [PATCH -next] power_supply: fix sysfs format warning
From: Randy Dunlap @ 2011-08-22 18:30 UTC (permalink / raw)
To: Stephen Rothwell, Anton Vorontsov, David Woodhouse; +Cc: linux-next, LKML
In-Reply-To: <20110822145304.980529cb921e5f1321c622da@canb.auug.org.au>
From: Randy Dunlap <rdunlap@xenotime.net>
Fix format warning:
drivers/power/power_supply_sysfs.c:82: warning: format '%d' expects type 'int', but argument 4 has type 'ssize_t'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
drivers/power/power_supply_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20110822.orig/drivers/power/power_supply_sysfs.c
+++ linux-next-20110822/drivers/power/power_supply_sysfs.c
@@ -78,7 +78,7 @@ static ssize_t power_supply_show_propert
dev_dbg(dev, "driver has no data for `%s' property\n",
attr->attr.name);
else if (ret != -ENODEV)
- dev_err(dev, "driver failed to report `%s' property: %d\n",
+ dev_err(dev, "driver failed to report `%s' property: %zd\n",
attr->attr.name, ret);
return ret;
}
^ permalink raw reply
* Re: linux-next: Tree for Aug 22 (evm)
From: Randy Dunlap @ 2011-08-22 19:53 UTC (permalink / raw)
To: Stephen Rothwell, Mimi Zohar; +Cc: linux-next, LKML, linux-kbuild
In-Reply-To: <20110822145304.980529cb921e5f1321c622da@canb.auug.org.au>
On Mon, 22 Aug 2011 14:53:04 +1000 Stephen Rothwell wrote:
> Hi all,
>
> [The kernel.org mirroring is a bit low today]
(on x86_64:)
When CONFIG_EVM=y, CONFIG_CRYPTO_HASH2=m, CONFIG_TRUSTED_KEYS=m,
CONFIG_ENCRYPTED_KEYS=m, the build fails with:
(.text+0x378aa): undefined reference to `key_type_encrypted'
evm_crypto.c:(.text+0x37992): undefined reference to `crypto_alloc_shash'
evm_crypto.c:(.text+0x37a24): undefined reference to `crypto_shash_setkey'
evm_crypto.c:(.text+0x37ad9): undefined reference to `crypto_shash_update'
evm_crypto.c:(.text+0x37aeb): undefined reference to `crypto_shash_final'
(.text+0x37b4b): undefined reference to `crypto_shash_update'
(.text+0x37c61): undefined reference to `crypto_shash_update'
(.text+0x37cb9): undefined reference to `crypto_shash_update'
even though EVM (Kconfig) selects ENCRYPTED_KEYS and TRUSTED_KEYS..
and even after I add "select CRYPTO_HASH2".
Is this because EVM is bool and kconfig is confused about 'select's
when a bool is selecting tristates? Shouldn't the tristates become
'y' instead of 'm' if they are selected by a bool that is 'y'?
xconfig shows these symbol values:
Symbol: EVM [=y]
Type : boolean
Prompt: EVM support
Defined at security/integrity/evm/Kconfig:1
Depends on: SECURITY [=y] && KEYS [=y] && TCG_TPM [=m]
Location:
-> Security options
Selects: CRYPTO_HMAC [=m] && CRYPTO_MD5 [=m] && CRYPTO_SHA1 [=m] && CRYPTO_HASH2 [=m] && ENCRYPTED_KEYS [=m] && TRUSTED_KEYS [=m]
Hm, changing TCG_TPM to =y also changes TRUSTED_KEYS and ENCRYPTED_KEYS and
lots of CRYPTO_ symbols from =m to =y. There must be some kind of min/max
symbol checking that is confused?
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: Tree for Aug 22 (evm)
From: Arnaud Lacombe @ 2011-08-22 20:18 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, Mimi Zohar, linux-next, LKML, linux-kbuild
In-Reply-To: <20110822125355.bb01d76b.rdunlap@xenotime.net>
Hi,
On Mon, Aug 22, 2011 at 3:53 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On Mon, 22 Aug 2011 14:53:04 +1000 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> [The kernel.org mirroring is a bit low today]
>
> (on x86_64:)
>
> When CONFIG_EVM=y, CONFIG_CRYPTO_HASH2=m, CONFIG_TRUSTED_KEYS=m,
> CONFIG_ENCRYPTED_KEYS=m, the build fails with:
>
> (.text+0x378aa): undefined reference to `key_type_encrypted'
> evm_crypto.c:(.text+0x37992): undefined reference to `crypto_alloc_shash'
> evm_crypto.c:(.text+0x37a24): undefined reference to `crypto_shash_setkey'
> evm_crypto.c:(.text+0x37ad9): undefined reference to `crypto_shash_update'
> evm_crypto.c:(.text+0x37aeb): undefined reference to `crypto_shash_final'
> (.text+0x37b4b): undefined reference to `crypto_shash_update'
> (.text+0x37c61): undefined reference to `crypto_shash_update'
> (.text+0x37cb9): undefined reference to `crypto_shash_update'
>
> even though EVM (Kconfig) selects ENCRYPTED_KEYS and TRUSTED_KEYS..
> and even after I add "select CRYPTO_HASH2".
>
> Is this because EVM is bool and kconfig is confused about 'select's
> when a bool is selecting tristates? Shouldn't the tristates become
> 'y' instead of 'm' if they are selected by a bool that is 'y'?
>
hum, I'd say that it should:
% cat Kconfig
config MOD
bool
default y
option modules
config B
tristate "B"
default m
config A
tristate "A"
default y
select B
% make alldefconfig
scripts/kconfig/conf --alldefconfig Kconfig
#
# configuration written to .config
#
% cat .config
#
# Automatically generated file; DO NOT EDIT.
# Linux Kernel Configuration
#
CONFIG_MOD=y
CONFIG_B=y
CONFIG_A=y
now, if A defaults to 'm', we have:
% cat .config
#
# Automatically generated file; DO NOT EDIT.
# Linux Kernel Configuration
#
CONFIG_MOD=y
CONFIG_B=m
CONFIG_A=m
Could you please produce a reduced testcase showing the problem ?
Thanks,
- Arnaud
>
> xconfig shows these symbol values:
>
> Symbol: EVM [=y]
> Type : boolean
> Prompt: EVM support
> Defined at security/integrity/evm/Kconfig:1
> Depends on: SECURITY [=y] && KEYS [=y] && TCG_TPM [=m]
> Location:
> -> Security options
> Selects: CRYPTO_HMAC [=m] && CRYPTO_MD5 [=m] && CRYPTO_SHA1 [=m] && CRYPTO_HASH2 [=m] && ENCRYPTED_KEYS [=m] && TRUSTED_KEYS [=m]
>
>
> Hm, changing TCG_TPM to =y also changes TRUSTED_KEYS and ENCRYPTED_KEYS and
> lots of CRYPTO_ symbols from =m to =y. There must be some kind of min/max
> symbol checking that is confused?
>
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* linux next: Native Linux KVM tool inclusion request
From: Sasha Levin @ 2011-08-22 20:29 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-kernel, Avi Kivity, Ingo Molnar, Andrew Morton,
Linus Torvalds, Pekka Enberg, linux-next
Hello Stephen,
I would like to ask you to include the Native Linux KVM tool in the
linux-next tree.
The branch is named 'master' and is located in:
git://github.com/penberg/linux-kvm.git
Thanks!
--
Sasha.
^ permalink raw reply
* Re: linux next: Native Linux KVM tool inclusion request
From: Christoph Hellwig @ 2011-08-23 0:39 UTC (permalink / raw)
To: Sasha Levin
Cc: Stephen Rothwell, linux-kernel, Avi Kivity, Ingo Molnar,
Andrew Morton, Linus Torvalds, Pekka Enberg, linux-next
In-Reply-To: <1314044960.3668.9.camel@lappy>
On Mon, Aug 22, 2011 at 11:29:20PM +0300, Sasha Levin wrote:
> Hello Stephen,
>
> I would like to ask you to include the Native Linux KVM tool in the
> linux-next tree.
What has changed over the last rejection of it? Again, I'm not against
the tool, but there is no reason to throw it into the kernel tree with
a completely misleading name.
^ permalink raw reply
* Re: linux-next: Tree for Aug 22 (evm)
From: Arnaud Lacombe @ 2011-08-23 0:47 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, Mimi Zohar, linux-next, LKML, linux-kbuild
In-Reply-To: <20110822125355.bb01d76b.rdunlap@xenotime.net>
Hi,
On Mon, Aug 22, 2011 at 3:53 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On Mon, 22 Aug 2011 14:53:04 +1000 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> [The kernel.org mirroring is a bit low today]
>
> (on x86_64:)
>
> When CONFIG_EVM=y, CONFIG_CRYPTO_HASH2=m, CONFIG_TRUSTED_KEYS=m,
> CONFIG_ENCRYPTED_KEYS=m, the build fails with:
>
You did not provide the value of CONFIG_TCG_TPM, I'll assume it was
'm'. That said, correct me if I'm wrong, but we currently have:
menuconfig TCG_TPM
tristate "TPM Hardware Support"
[...]
config EVM
boolean "EVM support"
depends on SECURITY && KEYS && TCG_TPM
which seems terribly broken to me... How can you have a built-in
feature, which depends on another potentially-not-built-in feature ?
If you change EVM to 'tristate', you will see that you are not allowed
to make it built-in if TCG_TPM is not built-in.
- Arnaud
> (.text+0x378aa): undefined reference to `key_type_encrypted'
> evm_crypto.c:(.text+0x37992): undefined reference to `crypto_alloc_shash'
> evm_crypto.c:(.text+0x37a24): undefined reference to `crypto_shash_setkey'
> evm_crypto.c:(.text+0x37ad9): undefined reference to `crypto_shash_update'
> evm_crypto.c:(.text+0x37aeb): undefined reference to `crypto_shash_final'
> (.text+0x37b4b): undefined reference to `crypto_shash_update'
> (.text+0x37c61): undefined reference to `crypto_shash_update'
> (.text+0x37cb9): undefined reference to `crypto_shash_update'
>
> even though EVM (Kconfig) selects ENCRYPTED_KEYS and TRUSTED_KEYS..
> and even after I add "select CRYPTO_HASH2".
>
> Is this because EVM is bool and kconfig is confused about 'select's
> when a bool is selecting tristates? Shouldn't the tristates become
> 'y' instead of 'm' if they are selected by a bool that is 'y'?
>
>
> xconfig shows these symbol values:
>
> Symbol: EVM [=y]
> Type : boolean
> Prompt: EVM support
> Defined at security/integrity/evm/Kconfig:1
> Depends on: SECURITY [=y] && KEYS [=y] && TCG_TPM [=m]
> Location:
> -> Security options
> Selects: CRYPTO_HMAC [=m] && CRYPTO_MD5 [=m] && CRYPTO_SHA1 [=m] && CRYPTO_HASH2 [=m] && ENCRYPTED_KEYS [=m] && TRUSTED_KEYS [=m]
>
>
> Hm, changing TCG_TPM to =y also changes TRUSTED_KEYS and ENCRYPTED_KEYS and
> lots of CRYPTO_ symbols from =m to =y. There must be some kind of min/max
> symbol checking that is confused?
>
there is definitively an underlying min/max, but I would not point
finger too fast.
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: Tree for Aug 22 (evm)
From: Randy Dunlap @ 2011-08-23 0:49 UTC (permalink / raw)
To: Arnaud Lacombe
Cc: Stephen Rothwell, Mimi Zohar, linux-next, LKML, linux-kbuild
In-Reply-To: <CACqU3MVjg60pTPyNWm+41w144QzPgtHQ4wZPUUV=vok8gGffuQ@mail.gmail.com>
On Mon, 22 Aug 2011 20:47:00 -0400 Arnaud Lacombe wrote:
> Hi,
>
> On Mon, Aug 22, 2011 at 3:53 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> > On Mon, 22 Aug 2011 14:53:04 +1000 Stephen Rothwell wrote:
> >
> >> Hi all,
> >>
> >> [The kernel.org mirroring is a bit low today]
> >
> > (on x86_64:)
> >
> > When CONFIG_EVM=y, CONFIG_CRYPTO_HASH2=m, CONFIG_TRUSTED_KEYS=m,
> > CONFIG_ENCRYPTED_KEYS=m, the build fails with:
> >
> You did not provide the value of CONFIG_TCG_TPM, I'll assume it was
> 'm'. That said, correct me if I'm wrong, but we currently have:
Yes, it was 'm'.
> menuconfig TCG_TPM
> tristate "TPM Hardware Support"
>
> [...]
>
> config EVM
> boolean "EVM support"
> depends on SECURITY && KEYS && TCG_TPM
>
> which seems terribly broken to me... How can you have a built-in
> feature, which depends on another potentially-not-built-in feature ?
Yup.
> If you change EVM to 'tristate', you will see that you are not allowed
> to make it built-in if TCG_TPM is not built-in.
Right.
> - Arnaud
>
> > (.text+0x378aa): undefined reference to `key_type_encrypted'
> > evm_crypto.c:(.text+0x37992): undefined reference to `crypto_alloc_shash'
> > evm_crypto.c:(.text+0x37a24): undefined reference to `crypto_shash_setkey'
> > evm_crypto.c:(.text+0x37ad9): undefined reference to `crypto_shash_update'
> > evm_crypto.c:(.text+0x37aeb): undefined reference to `crypto_shash_final'
> > (.text+0x37b4b): undefined reference to `crypto_shash_update'
> > (.text+0x37c61): undefined reference to `crypto_shash_update'
> > (.text+0x37cb9): undefined reference to `crypto_shash_update'
> >
> > even though EVM (Kconfig) selects ENCRYPTED_KEYS and TRUSTED_KEYS..
> > and even after I add "select CRYPTO_HASH2".
> >
> > Is this because EVM is bool and kconfig is confused about 'select's
> > when a bool is selecting tristates? Shouldn't the tristates become
> > 'y' instead of 'm' if they are selected by a bool that is 'y'?
> >
> >
> > xconfig shows these symbol values:
> >
> > Symbol: EVM [=y]
> > Type : boolean
> > Prompt: EVM support
> > Defined at security/integrity/evm/Kconfig:1
> > Depends on: SECURITY [=y] && KEYS [=y] && TCG_TPM [=m]
> > Location:
> > -> Security options
> > Selects: CRYPTO_HMAC [=m] && CRYPTO_MD5 [=m] && CRYPTO_SHA1 [=m] && CRYPTO_HASH2 [=m] && ENCRYPTED_KEYS [=m] && TRUSTED_KEYS [=m]
> >
> >
> > Hm, changing TCG_TPM to =y also changes TRUSTED_KEYS and ENCRYPTED_KEYS and
> > lots of CRYPTO_ symbols from =m to =y. There must be some kind of min/max
> > symbol checking that is confused?
> >
> there is definitively an underlying min/max, but I would not point
> finger too fast.
Thanks for your help.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-23 1:40 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher, mikey,
torvalds, akpm, ppc-dev, Benjamin Herrenschmidt, Paul Mackerras
In-Reply-To: <20110822113032.15087c2e190e2b0c3ee7dfb8@canb.auug.org.au>
Hi Dave,
On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Here's what I am applying as a merge fixup to the net tree today so that
> my ppc64_defconfig builds actually build more or less the same set of
> drivers as before this rearrangement.
And this today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 23 Aug 2011 11:23:40 +1000
Subject: [PATCH] sparc: update sparc32_defconfig for net device movement
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/sparc/configs/sparc32_defconfig | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/sparc/configs/sparc32_defconfig b/arch/sparc/configs/sparc32_defconfig
index fb23fd6..9bc241a 100644
--- a/arch/sparc/configs/sparc32_defconfig
+++ b/arch/sparc/configs/sparc32_defconfig
@@ -2,9 +2,7 @@ CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_LOG_BUF_SHIFT=14
-CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
@@ -42,9 +40,10 @@ CONFIG_SCSI_QLOGICPTI=m
CONFIG_SCSI_SUNESP=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
-CONFIG_NET_ETHERNET=y
CONFIG_MII=m
+CONFIG_NET_VENDOR_AMD=y
CONFIG_SUNLANCE=y
+CONFIG_NET_VENDOR_SUN=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNBMAC=m
CONFIG_SUNQE=m
@@ -64,26 +63,22 @@ CONFIG_SERIAL_SUNSU=y
CONFIG_SERIAL_SUNSU_CONSOLE=y
CONFIG_SPI=y
CONFIG_SPI_XILINX=m
-CONFIG_SPI_XILINX_PLTFM=m
CONFIG_SUN_OPENPROMIO=m
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
-CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_ISO9660_FS=m
CONFIG_PROC_KCORE=y
CONFIG_ROMFS_FS=m
CONFIG_NFS_FS=y
CONFIG_ROOT_NFS=y
-CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_NLS=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_DETECT_HUNG_TASK=y
# CONFIG_SCHED_DEBUG is not set
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
CONFIG_KGDB=y
CONFIG_KGDB_TESTS=y
CONFIG_CRYPTO_NULL=m
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-23 1:41 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher, mikey,
torvalds, akpm, ppc-dev, Benjamin Herrenschmidt, Paul Mackerras
In-Reply-To: <20110823114011.a059aea0138b75bfa7eed1ce@canb.auug.org.au>
Hi Dave,
On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Here's what I am applying as a merge fixup to the net tree today so that
> > my ppc64_defconfig builds actually build more or less the same set of
> > drivers as before this rearrangement.
>
> And this today:
And this:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 23 Aug 2011 11:35:18 +1000
Subject: [PATCH] sparc: update sparc64_defconfig for net device movement
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/sparc/configs/sparc64_defconfig | 20 +++++++++-----------
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/sparc/configs/sparc64_defconfig b/arch/sparc/configs/sparc64_defconfig
index 3c1e858..5732728 100644
--- a/arch/sparc/configs/sparc64_defconfig
+++ b/arch/sparc/configs/sparc64_defconfig
@@ -37,8 +37,6 @@ CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_NET_IPIP=m
-CONFIG_NET_IPGRE=m
-CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
@@ -95,17 +93,19 @@ CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_NETDEVICES=y
-CONFIG_NET_ETHERNET=y
CONFIG_MII=m
+CONFIG_NET_VENDOR_AMD=y
CONFIG_SUNLANCE=m
+CONFIG_NET_VENDOR_BROADCOM=y
+CONFIG_BNX2=m
+CONFIG_TIGON3=m
+CONFIG_NET_VENDOR_INTEL=y
+CONFIG_E1000=m
+CONFIG_E1000E=m
+CONFIG_NET_VENDOR_SUN=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_SUNVNET=m
-CONFIG_NET_PCI=y
-CONFIG_E1000=m
-CONFIG_E1000E=m
-CONFIG_TIGON3=m
-CONFIG_BNX2=m
CONFIG_NIU=m
# CONFIG_WLAN is not set
CONFIG_PPP=m
@@ -126,13 +126,13 @@ CONFIG_INPUT_SPARCSPKR=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_RAW=m
+# CONFIG_LEGACY_PTYS is not set
# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_SUNSU=y
CONFIG_SERIAL_SUNSU_CONSOLE=y
CONFIG_SERIAL_SUNSAB=y
CONFIG_SERIAL_SUNSAB_CONSOLE=y
CONFIG_SERIAL_SUNHV=y
-# CONFIG_LEGACY_PTYS is not set
CONFIG_FB=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_SBUS=y
@@ -206,10 +206,8 @@ CONFIG_PRINTK_TIME=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_LOCKUP_DETECTOR=y
-CONFIG_DETECT_HUNG_TASK=y
# CONFIG_SCHED_DEBUG is not set
CONFIG_SCHEDSTATS=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_KEYS=y
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: linux-next: Tree for Aug 22 (evm)
From: Mimi Zohar @ 2011-08-23 2:09 UTC (permalink / raw)
To: Randy Dunlap
Cc: Arnaud Lacombe, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
In-Reply-To: <20110822174958.73dd96c7.rdunlap@xenotime.net>
On Mon, 2011-08-22 at 17:49 -0700, Randy Dunlap wrote:
> On Mon, 22 Aug 2011 20:47:00 -0400 Arnaud Lacombe wrote:
>
> > Hi,
> >
> > On Mon, Aug 22, 2011 at 3:53 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> > > On Mon, 22 Aug 2011 14:53:04 +1000 Stephen Rothwell wrote:
> > >
> > >> Hi all,
> > >>
> > >> [The kernel.org mirroring is a bit low today]
> > >
> > > (on x86_64:)
> > >
> > > When CONFIG_EVM=y, CONFIG_CRYPTO_HASH2=m, CONFIG_TRUSTED_KEYS=m,
> > > CONFIG_ENCRYPTED_KEYS=m, the build fails with:
> > >
> > You did not provide the value of CONFIG_TCG_TPM, I'll assume it was
> > 'm'. That said, correct me if I'm wrong, but we currently have:
>
> Yes, it was 'm'.
>
> > menuconfig TCG_TPM
> > tristate "TPM Hardware Support"
> >
> > [...]
> >
> > config EVM
> > boolean "EVM support"
> > depends on SECURITY && KEYS && TCG_TPM
> >
> > which seems terribly broken to me... How can you have a built-in
> > feature, which depends on another potentially-not-built-in feature ?
>
> Yup.
Easy, different use cases. The TPM has been around and used for a while,
not requiring it to be built-in. EVM, a new use case, requires it to be
built-in.
> > If you change EVM to 'tristate', you will see that you are not allowed
> > to make it built-in if TCG_TPM is not built-in.
>
> Right.
The TPM, crypto, trusted and encrypted keys are tristate. Like the
LSMs, EVM is boolean, which when selected using 'make xconfig', converts
the tristates to built-in. The tristate/boolean mismatches aren't
corrected, when .config is edited directly.
Mimi
> > - Arnaud
> >
> > > (.text+0x378aa): undefined reference to `key_type_encrypted'
> > > evm_crypto.c:(.text+0x37992): undefined reference to `crypto_alloc_shash'
> > > evm_crypto.c:(.text+0x37a24): undefined reference to `crypto_shash_setkey'
> > > evm_crypto.c:(.text+0x37ad9): undefined reference to `crypto_shash_update'
> > > evm_crypto.c:(.text+0x37aeb): undefined reference to `crypto_shash_final'
> > > (.text+0x37b4b): undefined reference to `crypto_shash_update'
> > > (.text+0x37c61): undefined reference to `crypto_shash_update'
> > > (.text+0x37cb9): undefined reference to `crypto_shash_update'
> > >
> > > even though EVM (Kconfig) selects ENCRYPTED_KEYS and TRUSTED_KEYS..
> > > and even after I add "select CRYPTO_HASH2".
> > >
> > > Is this because EVM is bool and kconfig is confused about 'select's
> > > when a bool is selecting tristates? Shouldn't the tristates become
> > > 'y' instead of 'm' if they are selected by a bool that is 'y'?
> > >
> > >
> > > xconfig shows these symbol values:
> > >
> > > Symbol: EVM [=y]
> > > Type : boolean
> > > Prompt: EVM support
> > > Defined at security/integrity/evm/Kconfig:1
> > > Depends on: SECURITY [=y] && KEYS [=y] && TCG_TPM [=m]
> > > Location:
> > > -> Security options
> > > Selects: CRYPTO_HMAC [=m] && CRYPTO_MD5 [=m] && CRYPTO_SHA1 [=m] && CRYPTO_HASH2 [=m] && ENCRYPTED_KEYS [=m] && TRUSTED_KEYS [=m]
> > >
> > >
> > > Hm, changing TCG_TPM to =y also changes TRUSTED_KEYS and ENCRYPTED_KEYS and
> > > lots of CRYPTO_ symbols from =m to =y. There must be some kind of min/max
> > > symbol checking that is confused?
> > >
> > there is definitively an underlying min/max, but I would not point
> > finger too fast.
>
>
> Thanks for your help.
>
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-23 2:13 UTC (permalink / raw)
To: sfr
Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher, mikey,
torvalds, akpm, linuxppc-dev, benh, paulus
In-Reply-To: <20110823114129.ceb18da164bf7df3c145941b@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 23 Aug 2011 11:41:29 +1000
> On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >
>> > Here's what I am applying as a merge fixup to the net tree today so that
>> > my ppc64_defconfig builds actually build more or less the same set of
>> > drivers as before this rearrangement.
>>
>> And this today:
>
> And this:
I'm starting to get uncomfortable with this whole situation, and I
feel more and more that these new kconfig guards are not tenable.
Changing defconfig files might fix the "automated test boot with
defconfig" case but it won't fix the case of someone trying to
automate a build and boot using a different, existing, config file.
It ought to work too, and I do know people really do this.
And just the fact that we would have to merge all of these defconfig changes
through the networking tree is evidence of how it's really not reasonable
to be doing things this way.
Jeff, I think we need to revert the dependencies back to what they were
before the drivers/net moves. Could you prepare a patch which does that?
^ permalink raw reply
* Re: linux-next: Tree for Aug 22 (evm)
From: Arnaud Lacombe @ 2011-08-23 2:24 UTC (permalink / raw)
To: Mimi Zohar
Cc: Randy Dunlap, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
In-Reply-To: <1314065358.3225.44.camel@localhost.localdomain>
Hi,
On Mon, Aug 22, 2011 at 10:09 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Mon, 2011-08-22 at 17:49 -0700, Randy Dunlap wrote:
>> On Mon, 22 Aug 2011 20:47:00 -0400 Arnaud Lacombe wrote:
>>
>> > Hi,
>> >
>> > On Mon, Aug 22, 2011 at 3:53 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>> > > On Mon, 22 Aug 2011 14:53:04 +1000 Stephen Rothwell wrote:
>> > >
>> > >> Hi all,
>> > >>
>> > >> [The kernel.org mirroring is a bit low today]
>> > >
>> > > (on x86_64:)
>> > >
>> > > When CONFIG_EVM=y, CONFIG_CRYPTO_HASH2=m, CONFIG_TRUSTED_KEYS=m,
>> > > CONFIG_ENCRYPTED_KEYS=m, the build fails with:
>> > >
>> > You did not provide the value of CONFIG_TCG_TPM, I'll assume it was
>> > 'm'. That said, correct me if I'm wrong, but we currently have:
>>
>> Yes, it was 'm'.
>>
>> > menuconfig TCG_TPM
>> > tristate "TPM Hardware Support"
>> >
>> > [...]
>> >
>> > config EVM
>> > boolean "EVM support"
>> > depends on SECURITY && KEYS && TCG_TPM
>> >
>> > which seems terribly broken to me... How can you have a built-in
>> > feature, which depends on another potentially-not-built-in feature ?
>>
>> Yup.
>
> Easy, different use cases. The TPM has been around and used for a while,
> not requiring it to be built-in. EVM, a new use case, requires it to be
> built-in.
>
What behavior is expected when TPM is built as a module ? Would you
expect EVM to be accessible ?
>> > If you change EVM to 'tristate', you will see that you are not allowed
>> > to make it built-in if TCG_TPM is not built-in.
>>
>> Right.
>
> The TPM, crypto, trusted and encrypted keys are tristate. Like the
> LSMs, EVM is boolean, which when selected using 'make xconfig', converts
> the tristates to built-in. The tristate/boolean mismatches aren't
> corrected, when .config is edited directly.
>
well, ... no. 'xconfig' would seem to let you think they have been
changed to 'y', but they have not. I have been able to generate a bad
configuration (TPM module, EVM built-in) using only {menu,x}config.
btw, I never edit the configuration manually, there is a big fat "DO
NOT EDIT" header in the beginning.
Depending on what you expect, one way to fix that is to make EVM
depends on TCG_TPM = y, not just TCG_TPM.
- Arnaud
> Mimi
>
>> > - Arnaud
>> >
>> > > (.text+0x378aa): undefined reference to `key_type_encrypted'
>> > > evm_crypto.c:(.text+0x37992): undefined reference to `crypto_alloc_shash'
>> > > evm_crypto.c:(.text+0x37a24): undefined reference to `crypto_shash_setkey'
>> > > evm_crypto.c:(.text+0x37ad9): undefined reference to `crypto_shash_update'
>> > > evm_crypto.c:(.text+0x37aeb): undefined reference to `crypto_shash_final'
>> > > (.text+0x37b4b): undefined reference to `crypto_shash_update'
>> > > (.text+0x37c61): undefined reference to `crypto_shash_update'
>> > > (.text+0x37cb9): undefined reference to `crypto_shash_update'
>> > >
>> > > even though EVM (Kconfig) selects ENCRYPTED_KEYS and TRUSTED_KEYS..
>> > > and even after I add "select CRYPTO_HASH2".
>> > >
>> > > Is this because EVM is bool and kconfig is confused about 'select's
>> > > when a bool is selecting tristates? Shouldn't the tristates become
>> > > 'y' instead of 'm' if they are selected by a bool that is 'y'?
>> > >
>> > >
>> > > xconfig shows these symbol values:
>> > >
>> > > Symbol: EVM [=y]
>> > > Type : boolean
>> > > Prompt: EVM support
>> > > Defined at security/integrity/evm/Kconfig:1
>> > > Depends on: SECURITY [=y] && KEYS [=y] && TCG_TPM [=m]
>> > > Location:
>> > > -> Security options
>> > > Selects: CRYPTO_HMAC [=m] && CRYPTO_MD5 [=m] && CRYPTO_SHA1 [=m] && CRYPTO_HASH2 [=m] && ENCRYPTED_KEYS [=m] && TRUSTED_KEYS [=m]
>> > >
>> > >
>> > > Hm, changing TCG_TPM to =y also changes TRUSTED_KEYS and ENCRYPTED_KEYS and
>> > > lots of CRYPTO_ symbols from =m to =y. There must be some kind of min/max
>> > > symbol checking that is confused?
>> > >
>> > there is definitively an underlying min/max, but I would not point
>> > finger too fast.
>>
>>
>> Thanks for your help.
>>
>> ---
>> ~Randy
>> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Jeff Kirsher @ 2011-08-23 2:26 UTC (permalink / raw)
To: David Miller
Cc: sfr@canb.auug.org.au, netdev@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
mikey@neuling.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
benh@kernel.crashing.org, paulus@samba.org
In-Reply-To: <20110822.191348.2099822249437201579.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]
On Mon, 2011-08-22 at 19:13 -0700, David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 23 Aug 2011 11:41:29 +1000
>
> > On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >> >
> >> > Here's what I am applying as a merge fixup to the net tree today so that
> >> > my ppc64_defconfig builds actually build more or less the same set of
> >> > drivers as before this rearrangement.
> >>
> >> And this today:
> >
> > And this:
>
> I'm starting to get uncomfortable with this whole situation, and I
> feel more and more that these new kconfig guards are not tenable.
>
> Changing defconfig files might fix the "automated test boot with
> defconfig" case but it won't fix the case of someone trying to
> automate a build and boot using a different, existing, config file.
> It ought to work too, and I do know people really do this.
>
> And just the fact that we would have to merge all of these defconfig changes
> through the networking tree is evidence of how it's really not reasonable
> to be doing things this way.
>
> Jeff, I think we need to revert the dependencies back to what they were
> before the drivers/net moves. Could you prepare a patch which does that?
>
I was just finishing up those patches (not including any defconfig
changes) and started looking at a patch to fix/resolve the issues that
Stephen is seeing.
Let me see what I can come up with tonight to resolve this.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for Aug 22 (evm)
From: Arnaud Lacombe @ 2011-08-23 2:32 UTC (permalink / raw)
To: Mimi Zohar
Cc: Randy Dunlap, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
linux-kbuild
In-Reply-To: <1314065358.3225.44.camel@localhost.localdomain>
Hi,
On Mon, Aug 22, 2011 at 10:09 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Mon, 2011-08-22 at 17:49 -0700, Randy Dunlap wrote:
>> On Mon, 22 Aug 2011 20:47:00 -0400 Arnaud Lacombe wrote:
>>
>> > Hi,
>> >
>> > On Mon, Aug 22, 2011 at 3:53 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>> > > On Mon, 22 Aug 2011 14:53:04 +1000 Stephen Rothwell wrote:
>> > >
>> > >> Hi all,
>> > >>
>> > >> [The kernel.org mirroring is a bit low today]
>> > >
>> > > (on x86_64:)
>> > >
>> > > When CONFIG_EVM=y, CONFIG_CRYPTO_HASH2=m, CONFIG_TRUSTED_KEYS=m,
>> > > CONFIG_ENCRYPTED_KEYS=m, the build fails with:
>> > >
>> > You did not provide the value of CONFIG_TCG_TPM, I'll assume it was
>> > 'm'. That said, correct me if I'm wrong, but we currently have:
>>
>> Yes, it was 'm'.
>>
>> > menuconfig TCG_TPM
>> > tristate "TPM Hardware Support"
>> >
>> > [...]
>> >
>> > config EVM
>> > boolean "EVM support"
>> > depends on SECURITY && KEYS && TCG_TPM
>> >
>> > which seems terribly broken to me... How can you have a built-in
>> > feature, which depends on another potentially-not-built-in feature ?
>>
>> Yup.
>
> Easy, different use cases. The TPM has been around and used for a while,
> not requiring it to be built-in. EVM, a new use case, requires it to be
> built-in.
>
sorry, I think I misunderstood that last sentence. I assumed the 'it'
was referring to EVM, while taken in context with the previous
sentence, it might as well refers to TPM, in which case you want EVM
to 'depends on TCG_TPM = y'.
- Arnaud
>> > If you change EVM to 'tristate', you will see that you are not allowed
>> > to make it built-in if TCG_TPM is not built-in.
>>
>> Right.
>
> The TPM, crypto, trusted and encrypted keys are tristate. Like the
> LSMs, EVM is boolean, which when selected using 'make xconfig', converts
> the tristates to built-in. The tristate/boolean mismatches aren't
> corrected, when .config is edited directly.
>
> Mimi
>
>> > - Arnaud
>> >
>> > > (.text+0x378aa): undefined reference to `key_type_encrypted'
>> > > evm_crypto.c:(.text+0x37992): undefined reference to `crypto_alloc_shash'
>> > > evm_crypto.c:(.text+0x37a24): undefined reference to `crypto_shash_setkey'
>> > > evm_crypto.c:(.text+0x37ad9): undefined reference to `crypto_shash_update'
>> > > evm_crypto.c:(.text+0x37aeb): undefined reference to `crypto_shash_final'
>> > > (.text+0x37b4b): undefined reference to `crypto_shash_update'
>> > > (.text+0x37c61): undefined reference to `crypto_shash_update'
>> > > (.text+0x37cb9): undefined reference to `crypto_shash_update'
>> > >
>> > > even though EVM (Kconfig) selects ENCRYPTED_KEYS and TRUSTED_KEYS..
>> > > and even after I add "select CRYPTO_HASH2".
>> > >
>> > > Is this because EVM is bool and kconfig is confused about 'select's
>> > > when a bool is selecting tristates? Shouldn't the tristates become
>> > > 'y' instead of 'm' if they are selected by a bool that is 'y'?
>> > >
>> > >
>> > > xconfig shows these symbol values:
>> > >
>> > > Symbol: EVM [=y]
>> > > Type : boolean
>> > > Prompt: EVM support
>> > > Defined at security/integrity/evm/Kconfig:1
>> > > Depends on: SECURITY [=y] && KEYS [=y] && TCG_TPM [=m]
>> > > Location:
>> > > -> Security options
>> > > Selects: CRYPTO_HMAC [=m] && CRYPTO_MD5 [=m] && CRYPTO_SHA1 [=m] && CRYPTO_HASH2 [=m] && ENCRYPTED_KEYS [=m] && TRUSTED_KEYS [=m]
>> > >
>> > >
>> > > Hm, changing TCG_TPM to =y also changes TRUSTED_KEYS and ENCRYPTED_KEYS and
>> > > lots of CRYPTO_ symbols from =m to =y. There must be some kind of min/max
>> > > symbol checking that is confused?
>> > >
>> > there is definitively an underlying min/max, but I would not point
>> > finger too fast.
>>
>>
>> Thanks for your help.
>>
>> ---
>> ~Randy
>> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* linux-next: manual merge of the net tree with the unicore32 tree
From: Stephen Rothwell @ 2011-08-23 3:02 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Guan Xuetao, Zhang Shu, Chu Xiaowei,
Su Yonggang, Jeff Kirsher
Hi all,
Today's linux-next merge of the net tree got conflicts in
drivers/net/Kconfig and drivers/net/Makefile between commit e8787de6fa83
("unicore32: add pkunity-v3 mac/net driver (umal)") from the unicore32
tree and the network driver rearrangement from the net tree.
I just added the new driver from the unicore32 tree commit into each file
(see below).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ef6b6be..df5e990 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -215,6 +215,12 @@ source "drivers/s390/net/Kconfig"
source "drivers/net/caif/Kconfig"
+config MAC_PUV3
+ tristate "PKUnity v3 UMAL Gigabit Network Adapter support"
+ depends on UNICORE32 && ARCH_PUV3
+ select MII
+ select PHYLIB
+
config XEN_NETDEV_FRONTEND
tristate "Xen network device frontend driver"
depends on XEN
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index c33009b..9896ad1 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_RIONET) += rionet.o
obj-$(CONFIG_NET) += Space.o loopback.o
obj-$(CONFIG_NET_SB1000) += sb1000.o
+obj-$(CONFIG_MAC_PUV3) += mac-puv3.o
obj-$(CONFIG_PPP) += ppp_generic.o
obj-$(CONFIG_PPP_ASYNC) += ppp_async.o
obj-$(CONFIG_PPP_SYNC_TTY) += ppp_synctty.o
^ permalink raw reply related
* Re: linux-next: boot test failure (net tree)
From: Arnaud Lacombe @ 2011-08-23 3:50 UTC (permalink / raw)
To: David Miller
Cc: sfr, netdev, linux-next, linux-kernel, jeffrey.t.kirsher, mikey,
torvalds, akpm, linuxppc-dev, benh, paulus, linux-kbuild
In-Reply-To: <20110822.191348.2099822249437201579.davem@davemloft.net>
Hi,
[Added linux-kbuild@ to the Cc: list.]
On Mon, Aug 22, 2011 at 10:13 PM, David Miller <davem@davemloft.net> wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 23 Aug 2011 11:41:29 +1000
>
>> On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> >
>>> > Here's what I am applying as a merge fixup to the net tree today so that
>>> > my ppc64_defconfig builds actually build more or less the same set of
>>> > drivers as before this rearrangement.
>>>
>>> And this today:
>>
>> And this:
>
> I'm starting to get uncomfortable with this whole situation, and I
> feel more and more that these new kconfig guards are not tenable.
>
> Changing defconfig files might fix the "automated test boot with
> defconfig" case but it won't fix the case of someone trying to
> automate a build and boot using a different, existing, config file.
> It ought to work too, and I do know people really do this.
>
> And just the fact that we would have to merge all of these defconfig changes
> through the networking tree is evidence of how it's really not reasonable
> to be doing things this way.
>
> Jeff, I think we need to revert the dependencies back to what they were
> before the drivers/net moves. Could you prepare a patch which does that?
>
Are you implying we need some kind of way to migrate config ?
- Arnaud
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* linux-next: manual merge of the security tree with the ocfs2 tree
From: Stephen Rothwell @ 2011-08-23 3:52 UTC (permalink / raw)
To: James Morris
Cc: linux-next, linux-kernel, Tiger Yang, Joel Becker, Mimi Zohar
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]
Hi James,
Today's linux-next merge of the security tree got a conflict in
fs/ocfs2/xattr.c between commit d27fb6a99c41 ("ocfs2: free memory
allocated by inode_init_security") from the ocfs2 tree and commit
9d8f13ba3f48 ("security: new security_inode_init_security API adds
function callback") from the security tree.
I assume that the latter supercedes the former, so I used that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the pm tree with the mfd tree
From: Stephen Rothwell @ 2011-08-23 3:56 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-next, linux-kernel, Felipe Balbi, Samuel Ortiz, Mark Brown
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in
drivers/mfd/twl4030-irq.c between commit 99efe0d4c992 ("mfd: Drop the
twl4030-irq kthread") from the mfd tree and commit febab68efa45
("freezer: don't unnecessarily set PF_NOFREEZE explicitly") from the pm
tree.
The former dropped the code modified by the latter, so I did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-23 4:02 UTC (permalink / raw)
To: lacombar
Cc: sfr, netdev, linux-next, linux-kernel, jeffrey.t.kirsher, mikey,
torvalds, akpm, linuxppc-dev, benh, paulus, linux-kbuild
In-Reply-To: <CACqU3MW4BnucRt3gxPrKPDvWEjaVuxRF1VOPWk5hTRfneyANkg@mail.gmail.com>
From: Arnaud Lacombe <lacombar@gmail.com>
Date: Mon, 22 Aug 2011 23:50:02 -0400
> Are you implying we need some kind of way to migrate config ?
The issue is that the dependencies for every single ethernet driver
have changed. Some dependencies have been dropped (f.e. NETDEV_10000
and some have been added (f.e. ETHERNET, NET_VENDOR_****)
So right now an automated (non-prompted, default to no on all new
options) run on an existing config results in all ethernet drivers
getting disabled because the new dependencies don't get enabled.
This wouldn't be so bad if it was just one or two drivers, but in
this case it's every single ethernet driver which will have and hit
this problem.
^ permalink raw reply
* Re: linux next: Native Linux KVM tool inclusion request
From: Pekka Enberg @ 2011-08-23 5:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Sasha Levin, Stephen Rothwell, linux-kernel, Avi Kivity,
Ingo Molnar, Andrew Morton, Linus Torvalds, linux-next
In-Reply-To: <20110823003925.GA30253@infradead.org>
On Mon, Aug 22, 2011 at 11:29:20PM +0300, Sasha Levin wrote:
>> I would like to ask you to include the Native Linux KVM tool in the
>> linux-next tree.
On Tue, Aug 23, 2011 at 3:39 AM, Christoph Hellwig <hch@infradead.org> wrote:
> What has changed over the last rejection of it? Again, I'm not against
> the tool, but there is no reason to throw it into the kernel tree with
> a completely misleading name.
Linus didn't reject it but postponed his decision to the next merge
window. We're going to send a pull request for 3.2 so we'd like the
code to be in linux-next.
As for changes, we've implemented rootfs over 9p with "kvm run"
booting to host filesystem "/bin/sh" by default. It still needs some
work and we hope to enable networking too. We also have patches to use
overlayfs so that the guest is able to use host filesystem in
copy-on-write manner.
Pekka
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox