All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT
@ 2012-12-20 21:51 David Woodhouse
  2012-12-21  2:07 ` [tip:x86/build] x86: Default to ARCH= x86 " tip-bot for David Woodhouse
  2013-04-12 16:01 ` [PATCH] x86: Default to ARCH=x86 " richard -rw- weinberger
  0 siblings, 2 replies; 65+ messages in thread
From: David Woodhouse @ 2012-12-20 21:51 UTC (permalink / raw)
  To: x86, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3311 bytes --]

I *frequently* waste a bunch of time when I take a 32-bit .config from a
test machine and try to build it on a faster 64-bit system, and its
existing setting of CONFIG_64BIT=n gets *changed* to match the build host.

This is because the default setting for $ARCH when discovered from
'uname' is one of the legacy pre-x86-merge values (i386 or x86_64),
which effectively force the setting of CONFIG_64BIT to match. We should
default to ARCH=x86 instead, finally completing the merge that we
started so long ago.

This patch preserves the behaviour of the legacy ARCH settings for commands
such as:

   make ARCH=x86_64 randconfig
   make ARCH=i386 randconfig

... since making the value of CONFIG_64BIT actually random in that situation
is not desirable.

In time, perhaps we can retire this legacy use of the old ARCH= values.
We already have a way to override values for *any* config option, using
$KCONFIG_ALLCONFIG, so it could be argued that we don't necessarily need
to keep ARCH={i386,x86_64} around as a special case just for overriding
CONFIG_64BIT.

We'd probably at least want to add a way to override config options from
the command line ('make CONFIG_FOO=y oldconfig') before we talk about doing
that though.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
 Makefile                        | 3 ++-
 arch/x86/Kconfig                | 2 +-
 arch/x86/Makefile               | 4 ++++
 arch/x86/configs/i386_defconfig | 1 +
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 6f07f4a..19ee030 100644
--- a/Makefile
+++ b/Makefile
@@ -165,7 +165,8 @@ export srctree objtree VPATH
 # then ARCH is assigned, getting whatever value it gets normally, and 
 # SUBARCH is subsequently ignored.
 
-SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
+SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+				  -e s/sun4u/sparc64/ \
 				  -e s/arm.*/arm/ -e s/sa110/arm/ \
 				  -e s/s390x/s390/ -e s/parisc64/parisc/ \
 				  -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 97f8c5a..54a2f69 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1,7 +1,7 @@
 # Select 32 or 64 bit
 config 64BIT
 	bool "64-bit kernel" if ARCH = "x86"
-	default ARCH = "x86_64"
+	default ARCH != "i386"
 	---help---
 	  Say yes to build a 64-bit kernel - formerly known as x86_64
 	  Say no to build a 32-bit kernel - formerly known as i386
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index e71fc42..5c47726 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -2,7 +2,11 @@
 
 # select defconfig based on actual architecture
 ifeq ($(ARCH),x86)
+  ifeq ($(shell uname -m),x86_64)
+        KBUILD_DEFCONFIG := x86_64_defconfig
+  else
         KBUILD_DEFCONFIG := i386_defconfig
+  endif
 else
         KBUILD_DEFCONFIG := $(ARCH)_defconfig
 endif
diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index 5598547..9444708 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -1,3 +1,4 @@
+# CONFIG_64BIT is not set
 CONFIG_EXPERIMENTAL=y
 # CONFIG_LOCALVERSION_AUTO is not set
 CONFIG_SYSVIPC=y
-- 
1.8.0.1


-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

^ permalink raw reply related	[flat|nested] 65+ messages in thread

* [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2012-12-20 21:51 [PATCH] x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT David Woodhouse
@ 2012-12-21  2:07 ` tip-bot for David Woodhouse
  2012-12-26  6:32   ` David Rientjes
  2013-01-12 17:06   ` [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT Borislav Petkov
  2013-04-12 16:01 ` [PATCH] x86: Default to ARCH=x86 " richard -rw- weinberger
  1 sibling, 2 replies; 65+ messages in thread
From: tip-bot for David Woodhouse @ 2012-12-21  2:07 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: linux-kernel, hpa, mingo, dwmw2, tglx, hpa, David.Woodhouse

Commit-ID:  ffee0de411fd4f74f3b788892eeb075abbf26c52
Gitweb:     http://git.kernel.org/tip/ffee0de411fd4f74f3b788892eeb075abbf26c52
Author:     David Woodhouse <dwmw2@infradead.org>
AuthorDate: Thu, 20 Dec 2012 21:51:55 +0000
Committer:  H. Peter Anvin <hpa@linux.intel.com>
CommitDate: Thu, 20 Dec 2012 14:37:18 -0800

x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

It is easy to waste a bunch of time when one takes a 32-bit .config
from a test machine and try to build it on a faster 64-bit system, and
its existing setting of CONFIG_64BIT=n gets *changed* to match the
build host.  Similarly, if one has an existing build tree it is easy
to trash an entire build tree that way.

This is because the default setting for $ARCH when discovered from
'uname' is one of the legacy pre-x86-merge values (i386 or x86_64),
which effectively force the setting of CONFIG_64BIT to match. We should
default to ARCH=x86 instead, finally completing the merge that we
started so long ago.

This patch preserves the behaviour of the legacy ARCH settings for commands
such as:

   make ARCH=x86_64 randconfig
   make ARCH=i386 randconfig

... since making the value of CONFIG_64BIT actually random in that situation
is not desirable.

In time, perhaps we can retire this legacy use of the old ARCH= values.
We already have a way to override values for *any* config option, using
$KCONFIG_ALLCONFIG, so it could be argued that we don't necessarily need
to keep ARCH={i386,x86_64} around as a special case just for overriding
CONFIG_64BIT.

We'd probably at least want to add a way to override config options from
the command line ('make CONFIG_FOO=y oldconfig') before we talk about doing
that though.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Link: http://lkml.kernel.org/r/1356040315.3198.51.camel@shinybook.infradead.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
---
 Makefile                        | 3 ++-
 arch/x86/Kconfig                | 2 +-
 arch/x86/Makefile               | 4 ++++
 arch/x86/configs/i386_defconfig | 1 +
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 540f7b2..9a07340 100644
--- a/Makefile
+++ b/Makefile
@@ -165,7 +165,8 @@ export srctree objtree VPATH
 # then ARCH is assigned, getting whatever value it gets normally, and 
 # SUBARCH is subsequently ignored.
 
-SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
+SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+				  -e s/sun4u/sparc64/ \
 				  -e s/arm.*/arm/ -e s/sa110/arm/ \
 				  -e s/s390x/s390/ -e s/parisc64/parisc/ \
 				  -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 46c3bff..9084c7b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1,7 +1,7 @@
 # Select 32 or 64 bit
 config 64BIT
 	bool "64-bit kernel" if ARCH = "x86"
-	default ARCH = "x86_64"
+	default ARCH != "i386"
 	---help---
 	  Say yes to build a 64-bit kernel - formerly known as x86_64
 	  Say no to build a 32-bit kernel - formerly known as i386
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 05afcca..fa981ca 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -2,7 +2,11 @@
 
 # select defconfig based on actual architecture
 ifeq ($(ARCH),x86)
+  ifeq ($(shell uname -m),x86_64)
+        KBUILD_DEFCONFIG := x86_64_defconfig
+  else
         KBUILD_DEFCONFIG := i386_defconfig
+  endif
 else
         KBUILD_DEFCONFIG := $(ARCH)_defconfig
 endif
diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index 5598547..9444708 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -1,3 +1,4 @@
+# CONFIG_64BIT is not set
 CONFIG_EXPERIMENTAL=y
 # CONFIG_LOCALVERSION_AUTO is not set
 CONFIG_SYSVIPC=y

^ permalink raw reply related	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2012-12-21  2:07 ` [tip:x86/build] x86: Default to ARCH= x86 " tip-bot for David Woodhouse
@ 2012-12-26  6:32   ` David Rientjes
  2012-12-26  8:43     ` David Woodhouse
  2012-12-26 23:32     ` [tip] config: Add 'make kvmconfig' David Woodhouse
  2013-01-12 17:06   ` [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT Borislav Petkov
  1 sibling, 2 replies; 65+ messages in thread
From: David Rientjes @ 2012-12-26  6:32 UTC (permalink / raw)
  To: Ingo Molnar, H. Peter Anvin, dwmw2, tglx, H. Peter Anvin,
	David Woodhouse
  Cc: linux-kernel, linux-tip-commits

On Thu, 20 Dec 2012, tip-bot for David Woodhouse wrote:

> diff --git a/Makefile b/Makefile
> index 540f7b2..9a07340 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -165,7 +165,8 @@ export srctree objtree VPATH
>  # then ARCH is assigned, getting whatever value it gets normally, and 
>  # SUBARCH is subsequently ignored.
>  
> -SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
> +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
> +				  -e s/sun4u/sparc64/ \
>  				  -e s/arm.*/arm/ -e s/sa110/arm/ \
>  				  -e s/s390x/s390/ -e s/parisc64/parisc/ \
>  				  -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 46c3bff..9084c7b 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1,7 +1,7 @@
>  # Select 32 or 64 bit
>  config 64BIT
>  	bool "64-bit kernel" if ARCH = "x86"
> -	default ARCH = "x86_64"
> +	default ARCH != "i386"
>  	---help---
>  	  Say yes to build a 64-bit kernel - formerly known as x86_64
>  	  Say no to build a 32-bit kernel - formerly known as i386
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 05afcca..fa981ca 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -2,7 +2,11 @@
>  
>  # select defconfig based on actual architecture
>  ifeq ($(ARCH),x86)
> +  ifeq ($(shell uname -m),x86_64)
> +        KBUILD_DEFCONFIG := x86_64_defconfig
> +  else
>          KBUILD_DEFCONFIG := i386_defconfig
> +  endif
>  else
>          KBUILD_DEFCONFIG := $(ARCH)_defconfig
>  endif
> diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
> index 5598547..9444708 100644
> --- a/arch/x86/configs/i386_defconfig
> +++ b/arch/x86/configs/i386_defconfig
> @@ -1,3 +1,4 @@
> +# CONFIG_64BIT is not set
>  CONFIG_EXPERIMENTAL=y
>  # CONFIG_LOCALVERSION_AUTO is not set
>  CONFIG_SYSVIPC=y

This creates quite a few build failures on auto-latest:

arch/x86/built-in.o: In function `hpet_setup_msi_irq':
hpet.c:(.text+0x34638): undefined reference to `arch_setup_hpet_msi'
hpet.c:(.text+0x34651): undefined reference to `destroy_irq'
arch/x86/built-in.o: In function `hpet_msi_capability_lookup':
hpet.c:(.text+0x347ff): undefined reference to `create_irq_nr'
arch/x86/built-in.o:(.data+0xd1c): undefined reference to `native_setup_msi_irqs'
arch/x86/built-in.o:(.data+0xd20): undefined reference to `native_teardown_msi_irq'
drivers/built-in.o: In function `dmar_set_interrupt':
(.text+0x89eec0): undefined reference to `create_irq'
drivers/built-in.o: In function `dmar_set_interrupt':
(.text+0x89ef0b): undefined reference to `arch_setup_dmar_msi'
drivers/built-in.o: In function `dmar_set_interrupt':
(.text+0x89ef44): undefined reference to `destroy_irq'
drivers/built-in.o: In function `free_dmar_iommu':
(.text+0x8a6ae8): undefined reference to `destroy_irq'

These functions require CONFIG_X86_IO_APIC, which is only possible with 
X86_64 or X86_32_NON_STANDARD.  CONFIG_HPET_TIMER, however, can be enabled 
with X86_32, and CONFIG_DMAR_TABLE can be enabled with any X86 via 
CONFIG_INTEL_IOMMU.

That said, I didn't try to fix this up because I believe the commit itself 
is wrong.  When I do "make randconfig" and uname -m is x86_64, I expect 
CONFIG_64BIT to always be set.  This commit makes this random for all x86 
so that "make randconfig" may result in a 32-bit build.  That should be 
the behavior for "make ARCH=i386 randconfig" but not "make randconfig" on 
a 64-bit machine.

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2012-12-26  6:32   ` David Rientjes
@ 2012-12-26  8:43     ` David Woodhouse
  2012-12-26 10:44       ` David Rientjes
  2012-12-26 23:32     ` [tip] config: Add 'make kvmconfig' David Woodhouse
  1 sibling, 1 reply; 65+ messages in thread
From: David Woodhouse @ 2012-12-26  8:43 UTC (permalink / raw)
  To: David Rientjes
  Cc: Ingo Molnar, H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel,
	linux-tip-commits

[-- Attachment #1: Type: text/plain, Size: 2692 bytes --]

On Tue, 2012-12-25 at 22:32 -0800, David Rientjes wrote:
> This creates quite a few build failures on auto-latest:
>
> arch/x86/built-in.o: In function `hpet_setup_msi_irq':
> hpet.c:(.text+0x34638): undefined reference to `arch_setup_hpet_msi'
> hpet.c:(.text+0x34651): undefined reference to `destroy_irq'
> arch/x86/built-in.o: In function `hpet_msi_capability_lookup':
> hpet.c:(.text+0x347ff): undefined reference to `create_irq_nr'
> arch/x86/built-in.o:(.data+0xd1c): undefined reference to `native_setup_msi_irqs'
> arch/x86/built-in.o:(.data+0xd20): undefined reference to `native_teardown_msi_irq'
> drivers/built-in.o: In function `dmar_set_interrupt':
> (.text+0x89eec0): undefined reference to `create_irq'
> drivers/built-in.o: In function `dmar_set_interrupt':
> (.text+0x89ef0b): undefined reference to `arch_setup_dmar_msi'
> drivers/built-in.o: In function `dmar_set_interrupt':
> (.text+0x89ef44): undefined reference to `destroy_irq'
> drivers/built-in.o: In function `free_dmar_iommu':
> (.text+0x8a6ae8): undefined reference to `destroy_irq'
> 
> These functions require CONFIG_X86_IO_APIC, which is only possible with 
> X86_64 or X86_32_NON_STANDARD.  CONFIG_HPET_TIMER, however, can be enabled 
> with X86_32, and CONFIG_DMAR_TABLE can be enabled with any X86 via 
> CONFIG_INTEL_IOMMU.

I don't think it can have created them, surely? They must have existed
already when building with ARCH=x86. And probably with ARCH=i386 too?
I'll take a further look in more detail, but at first glance it doesn't
seem correct to describe them as bugs caused by this patch; merely bugs
that this patch helped us to *find*.

Please could you provide the .config file?

> That said, I didn't try to fix this up because I believe the commit itself 
> is wrong. 

That seems like completely the wrong approach.

>  When I do "make randconfig" and uname -m is x86_64, I expect 
> CONFIG_64BIT to always be set.  This commit makes this random for all x86 
> so that "make randconfig" may result in a 32-bit build.  That should be 
> the behavior for "make ARCH=i386 randconfig" but not "make randconfig" on 
> a 64-bit machine.

We've had this bizarre "I don't really want randconfig to be random"
conversation before. If don't want randconfig to be random, you can use
$KCONFIG_ALLCONFIG to override anything you like. Or, for the specific
case of CONFIG_64BIT on x86, you can use ARCH=i386 or ARCH=x86_64 to
override just that one option.

I'll look at the dependency problems that already existed, and try to
sort them out despite the fact that they seem unrelated to the patch I
posted. Thanks for reporting them.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2012-12-26  8:43     ` David Woodhouse
@ 2012-12-26 10:44       ` David Rientjes
  2012-12-26 12:38         ` David Woodhouse
  0 siblings, 1 reply; 65+ messages in thread
From: David Rientjes @ 2012-12-26 10:44 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Ingo Molnar, H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel,
	linux-tip-commits

On Wed, 26 Dec 2012, David Woodhouse wrote:

> > arch/x86/built-in.o: In function `hpet_setup_msi_irq':
> > hpet.c:(.text+0x34638): undefined reference to `arch_setup_hpet_msi'
> > hpet.c:(.text+0x34651): undefined reference to `destroy_irq'
> > arch/x86/built-in.o: In function `hpet_msi_capability_lookup':
> > hpet.c:(.text+0x347ff): undefined reference to `create_irq_nr'
> > arch/x86/built-in.o:(.data+0xd1c): undefined reference to `native_setup_msi_irqs'
> > arch/x86/built-in.o:(.data+0xd20): undefined reference to `native_teardown_msi_irq'
> > drivers/built-in.o: In function `dmar_set_interrupt':
> > (.text+0x89eec0): undefined reference to `create_irq'
> > drivers/built-in.o: In function `dmar_set_interrupt':
> > (.text+0x89ef0b): undefined reference to `arch_setup_dmar_msi'
> > drivers/built-in.o: In function `dmar_set_interrupt':
> > (.text+0x89ef44): undefined reference to `destroy_irq'
> > drivers/built-in.o: In function `free_dmar_iommu':
> > (.text+0x8a6ae8): undefined reference to `destroy_irq'
> > 
> > These functions require CONFIG_X86_IO_APIC, which is only possible with 
> > X86_64 or X86_32_NON_STANDARD.  CONFIG_HPET_TIMER, however, can be enabled 
> > with X86_32, and CONFIG_DMAR_TABLE can be enabled with any X86 via 
> > CONFIG_INTEL_IOMMU.
> 
> I don't think it can have created them, surely? They must have existed
> already when building with ARCH=x86. And probably with ARCH=i386 too?

I'm sure it's a 32-bit issue, nothing has changed recently in auto-latest 
related to these subsystems and I'm sure it's just because my randconfig 
builds were exposed to this combination solely because of this patch.

> I'll take a further look in more detail, but at first glance it doesn't
> seem correct to describe them as bugs caused by this patch; merely bugs
> that this patch helped us to *find*.
> 
> Please could you provide the .config file?
> 

Attached.

> >  When I do "make randconfig" and uname -m is x86_64, I expect 
> > CONFIG_64BIT to always be set.  This commit makes this random for all x86 
> > so that "make randconfig" may result in a 32-bit build.  That should be 
> > the behavior for "make ARCH=i386 randconfig" but not "make randconfig" on 
> > a 64-bit machine.
> 
> We've had this bizarre "I don't really want randconfig to be random"
> conversation before. If don't want randconfig to be random, you can use
> $KCONFIG_ALLCONFIG to override anything you like. Or, for the specific
> case of CONFIG_64BIT on x86, you can use ARCH=i386 or ARCH=x86_64 to
> override just that one option.
> 

If it were truly random then it would be generating sparc configs, hppa 
configs, etc.  Randconfig has always generated random configurations for 
the underlying architecture (just like you respect the architecture with 
defconfig with your patch), the fact that it's been unified into a single 
x86 architecture changes the behavior of plain old "make randconfig".  I 
certainly understand how to override that with ARCH=x86_64.  However, the 
reverse can also be said: make the same adjustment for randconfig that you 
made for defconfig so the old behavior is maintained and allow users on 
x86_64 to do "make ARCH=i386 randconfig" for 32-bit builds.

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2012-12-26 10:44       ` David Rientjes
@ 2012-12-26 12:38         ` David Woodhouse
  2012-12-26 22:00           ` David Rientjes
  0 siblings, 1 reply; 65+ messages in thread
From: David Woodhouse @ 2012-12-26 12:38 UTC (permalink / raw)
  To: David Rientjes
  Cc: Ingo Molnar, H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel,
	linux-tip-commits

[-- Attachment #1: Type: text/plain, Size: 3178 bytes --]

On Wed, 2012-12-26 at 02:44 -0800, David Rientjes wrote:
> I'm sure it's a 32-bit issue, nothing has changed recently in auto-latest 
> related to these subsystems and I'm sure it's just because my randconfig 
> builds were exposed to this combination solely because of this patch.

Hm, that's an unexpected benefit of this patch. I didn't think it would
noticeably improve 'make randconfig' coverage of configs without
CONFIG_64BIT, because I thought enough people were doing such tests
already. But evidently I was wrong.

We introduced 'make randconfig' as a tool to generate meaningless
configs just to test various permutations — to ensure that we got our
dependencies right both in Kconfig and the code itself. It was
artificially limiting its test coverage and thus we were failing to
discover real bugs. Now I've fixed that problem, and 'make randconfig'
is actually random and is thus doing its job even better than before.
Yay!

> > Please could you provide the .config file?

> Attached.

Didn't seem to be.

> > >  When I do "make randconfig" and uname -m is x86_64, I expect 
> > > CONFIG_64BIT to always be set.  This commit makes this random… 
> > 
> > We've had this bizarre "I don't really want randconfig to be random"
> > conversation before.
> 
> If it were truly random then it would be generating sparc configs, hppa 
> configs, etc.  Randconfig has always generated random configurations for 
> the underlying architecture (just like you respect the architecture with 
> defconfig with your patch),

Yes, but the underlying architecture is "x86". Just like the
architecture is "powerpc", not "ppc" or "ppc64". CONFIG_64BIT is just
another config option. And AFAICT this is also true for ARCH=sparc,
ARCH=parisc, ARCH=s390, ARCH=mips and ARCH=tile. We just hadn't
completed the merge of arch/i386 and arch/x86_64 into arch/x86 yet, so
it was inconsistent.

The architecture is *not* "i486", "i686 with PAT", "i686 with cmov",
"x86_64 with 3DNow", "x86_64 with AHCI and ext4", or anything else Aunt
Tillie-ish which actually stands a chance of booting on your current
hardware. If you want to fix the values of certain config options, we
*have* mechanisms to do that.

>  the fact that it's been unified into a single 
> x86 architecture changes the behavior of plain old "make randconfig".  I 
> certainly understand how to override that with ARCH=x86_64.  However, the 
> reverse can also be said: make the same adjustment for randconfig that you 
> made for defconfig so the old behavior is maintained and allow users on 
> x86_64 to do "make ARCH=i386 randconfig" for 32-bit builds.

You can already do 'make ARCH=i386 randconfig' for 32-bit builds. You
always could. Or, as less of a special-case hack, you could use other
methods to override *any* config option, rather than just CONFIG_64BIT.

I just don't buy this "OMG you made randconfig actually random" crap.
It's a stupid thing to complain about. Making some effort to pick
i386_defconfig or x86_64_defconfig according to the build host, we can
tolerate. But randconfig is *supposed* to be random. Get over it.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2012-12-26 12:38         ` David Woodhouse
@ 2012-12-26 22:00           ` David Rientjes
  2012-12-26 22:19             ` David Woodhouse
                               ` (3 more replies)
  0 siblings, 4 replies; 65+ messages in thread
From: David Rientjes @ 2012-12-26 22:00 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Ingo Molnar, H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel,
	linux-tip-commits

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2473 bytes --]

On Wed, 26 Dec 2012, David Woodhouse wrote:

> > I'm sure it's a 32-bit issue, nothing has changed recently in auto-latest 
> > related to these subsystems and I'm sure it's just because my randconfig 
> > builds were exposed to this combination solely because of this patch.
> 
> Hm, that's an unexpected benefit of this patch. I didn't think it would
> noticeably improve 'make randconfig' coverage of configs without
> CONFIG_64BIT, because I thought enough people were doing such tests
> already. But evidently I was wrong.
> 

I do quite a bit of automated config and boot tests to try out 
combinations that others may not have tested when developing their code; 
staging branches such as in tip are interesting to try because they 
haven't yet reached Linus and it's helpful to catch breakages before it 
reaches mainline.

> We introduced 'make randconfig' as a tool to generate meaningless
> configs just to test various permutations — to ensure that we got our
> dependencies right both in Kconfig and the code itself. It was
> artificially limiting its test coverage and thus we were failing to
> discover real bugs. Now I've fixed that problem, and 'make randconfig'
> is actually random and is thus doing its job even better than before.
> Yay!
> 

Umm, you're saying that is legitimate for "make randconfig" done on a 
32-bit machine to generate 64-bit configurations?  The resulting kernel 
cannot be booted.  In the past, "make randconfig" would always generate a 
kernel that _should_ boot on that machine unless there was an underlying 
bug that should be fixed.

> > > Please could you provide the .config file?
> 
> > Attached.
> 
> Didn't seem to be.
> 

Now it is, sorry.

> I just don't buy this "OMG you made randconfig actually random" crap.
> It's a stupid thing to complain about. Making some effort to pick
> i386_defconfig or x86_64_defconfig according to the build host, we can
> tolerate. But randconfig is *supposed* to be random. Get over it.
> 

I'm stupid for saying that you've changed the behavior of "make 
randconfig" with no ARCH= workaround so that it may result in an 
unbootable kernel on i386?  From the changelog of this commit, it looks 
like you're the idiot who can't remember he's building a 32-bit kernel on 
a 64-bit machine and is throwing a hissy fit because YOU forgot to put 
ARCH=i386.  But now you're pushing that obligation, which is a change from 
the previous behavior for years, on everyone else to workaround?

[-- Attachment #2: Type: TEXT/PLAIN, Size: 92766 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 3.8.0-rc1 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_GPIO=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_FHANDLE=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
# CONFIG_TICK_CPU_ACCOUNTING is not set
CONFIG_IRQ_TIME_ACCOUNTING=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
# CONFIG_IPC_NS is not set
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
# CONFIG_PRINTK is not set
# CONFIG_BUG is not set
# CONFIG_ELF_CORE is not set
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
# CONFIG_TIMERFD is not set
# CONFIG_EVENTFD is not set
# CONFIG_SHMEM is not set
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_PCI_QUIRKS is not set
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_TRACEPOINTS=y
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
# CONFIG_JUMP_LABEL is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_GENERIC_SIGALTSTACK=y
CONFIG_CLONE_BACKWARDS=y

#
# GCOV-based kernel profiling
#
CONFIG_GCOV_KERNEL=y
CONFIG_GCOV_PROFILE_ALL=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
# CONFIG_LBDAF is not set
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
CONFIG_ATARI_PARTITION=y
# CONFIG_MAC_PARTITION is not set
# CONFIG_MSDOS_PARTITION is not set
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
CONFIG_ULTRIX_PARTITION=y
# CONFIG_SUN_PARTITION is not set
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_ZONE_DMA=y
# CONFIG_SMP is not set
# CONFIG_X86_EXTENDED_PLATFORM is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_X86_32_IRIS=y
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
CONFIG_KVMTOOL_TEST_ENABLE=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_PARAVIRT_TIME_ACCOUNTING=y
# CONFIG_XEN_PRIVILEGED_GUEST is not set
# CONFIG_KVM_GUEST is not set
CONFIG_LGUEST_GUEST=y
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_DEBUG=y
CONFIG_NO_BOOTMEM=y
CONFIG_MEMTEST=y
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MELAN is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_INTERNODE_CACHE_SHIFT=5
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=5
CONFIG_X86_DEBUGCTLMSR=y
# CONFIG_PROCESSOR_SELECT is not set
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_CYRIX_32=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_CPU_SUP_UMC_32=y
CONFIG_HPET_TIMER=y
CONFIG_DMI=y
CONFIG_NR_CPUS=1
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_MCE=y
# CONFIG_X86_ANCIENT_MCE is not set
# CONFIG_X86_MCE_INJECT is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
CONFIG_I8K=y
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=y
# CONFIG_MICROCODE_INTEL is not set
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
# CONFIG_VMSPLIT_3G is not set
CONFIG_VMSPLIT_3G_OPT=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_2G_OPT is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xB0000000
CONFIG_HIGHMEM=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
# CONFIG_TRANSPARENT_HUGEPAGE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
# CONFIG_HIGHPTE is not set
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW=64
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
CONFIG_ARCH_RANDOM=y
CONFIG_X86_SMAP=y
# CONFIG_EFI is not set
# CONFIG_SECCOMP is not set
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_X86_NEED_RELOCS=y
CONFIG_PHYSICAL_ALIGN=0x1000000
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
CONFIG_PM_AUTOSLEEP=y
# CONFIG_PM_WAKELOCKS is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_EC_DEBUGFS=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_I2C=y
CONFIG_ACPI_PROCESSOR=y
# CONFIG_ACPI_IPMI is not set
# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
# CONFIG_ACPI_THERMAL is not set
CONFIG_ACPI_CUSTOM_DSDT_FILE=""
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_INITRD_TABLE_OVERRIDE=y
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_PCI_SLOT=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
CONFIG_ACPI_SBS=y
CONFIG_ACPI_HED=y
# CONFIG_ACPI_CUSTOM_METHOD is not set
CONFIG_ACPI_APEI=y
CONFIG_ACPI_APEI_GHES=y
# CONFIG_ACPI_APEI_EINJ is not set
CONFIG_ACPI_APEI_ERST_DEBUG=y
# CONFIG_SFI is not set
CONFIG_X86_APM_BOOT=y
CONFIG_APM=y
CONFIG_APM_IGNORE_USER_SUSPEND=y
CONFIG_APM_DO_ENABLE=y
# CONFIG_APM_CPU_IDLE is not set
CONFIG_APM_DISPLAY_BLANK=y
CONFIG_APM_ALLOW_INTS=y

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
CONFIG_INTEL_IDLE=y

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
# CONFIG_PCI_GOOLPC is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_OLPC=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_CNB20LE_QUIRK=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_PCI_MSI=y
CONFIG_PCI_DEBUG=y
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
# CONFIG_PCI_STUB is not set
CONFIG_PCI_ATS=y
CONFIG_PCI_IOV=y
# CONFIG_PCI_PRI is not set
CONFIG_PCI_PASID=y
CONFIG_PCI_IOAPIC=y
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_SCx200 is not set
CONFIG_OLPC=y
# CONFIG_OLPC_XO1_PM is not set
CONFIG_OLPC_XO15_SCI=y
CONFIG_ALIX=y
CONFIG_NET5501=y
CONFIG_GEOS=y
CONFIG_AMD_NB=y
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
# CONFIG_RAPIDIO is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_HAVE_AOUT=y
CONFIG_BINFMT_AOUT=y
# CONFIG_BINFMT_MISC is not set
CONFIG_COREDUMP=y
CONFIG_HAVE_ATOMIC_IOMAP=y
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_DIAG=y
CONFIG_UNIX=y
CONFIG_UNIX_DIAG=y
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=y
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_FIB_TRIE_STATS=y
# CONFIG_IP_MULTIPLE_TABLES is not set
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_ROUTE_CLASSID=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
CONFIG_NET_IPGRE_DEMUX=y
CONFIG_NET_IPGRE=y
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
CONFIG_INET_AH=y
# CONFIG_INET_ESP is not set
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
CONFIG_INET_XFRM_MODE_TUNNEL=y
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_ACCT=y
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
CONFIG_NETFILTER_NETLINK_LOG=y
# CONFIG_NF_CONNTRACK is not set
CONFIG_NETFILTER_TPROXY=y
CONFIG_NETFILTER_XTABLES=y

#
# Xtables combined modules
#
CONFIG_NETFILTER_XT_MARK=y

#
# Xtables targets
#
CONFIG_NETFILTER_XT_TARGET_CHECKSUM=y
# CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
# CONFIG_NETFILTER_XT_TARGET_HL is not set
# CONFIG_NETFILTER_XT_TARGET_HMARK is not set
CONFIG_NETFILTER_XT_TARGET_IDLETIMER=y
# CONFIG_NETFILTER_XT_TARGET_LOG is not set
# CONFIG_NETFILTER_XT_TARGET_MARK is not set
CONFIG_NETFILTER_XT_TARGET_NFLOG=y
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
CONFIG_NETFILTER_XT_TARGET_RATEEST=y
# CONFIG_NETFILTER_XT_TARGET_TEE is not set
# CONFIG_NETFILTER_XT_TARGET_TPROXY is not set
CONFIG_NETFILTER_XT_TARGET_TRACE=y
CONFIG_NETFILTER_XT_TARGET_SECMARK=y
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
# CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP is not set

#
# Xtables matches
#
# CONFIG_NETFILTER_XT_MATCH_ADDRTYPE is not set
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
CONFIG_NETFILTER_XT_MATCH_CPU=y
CONFIG_NETFILTER_XT_MATCH_DCCP=y
# CONFIG_NETFILTER_XT_MATCH_DEVGROUP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ECN is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=y
CONFIG_NETFILTER_XT_MATCH_HL=y
# CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set
CONFIG_NETFILTER_XT_MATCH_LENGTH=y
# CONFIG_NETFILTER_XT_MATCH_LIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_MAC is not set
CONFIG_NETFILTER_XT_MATCH_MARK=y
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
CONFIG_NETFILTER_XT_MATCH_NFACCT=y
# CONFIG_NETFILTER_XT_MATCH_OSF is not set
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
CONFIG_NETFILTER_XT_MATCH_POLICY=y
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=y
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
CONFIG_NETFILTER_XT_MATCH_QUOTA=y
CONFIG_NETFILTER_XT_MATCH_RATEEST=y
CONFIG_NETFILTER_XT_MATCH_REALM=y
# CONFIG_NETFILTER_XT_MATCH_RECENT is not set
CONFIG_NETFILTER_XT_MATCH_SCTP=y
CONFIG_NETFILTER_XT_MATCH_SOCKET=y
CONFIG_NETFILTER_XT_MATCH_STATISTIC=y
CONFIG_NETFILTER_XT_MATCH_STRING=y
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y
CONFIG_NETFILTER_XT_MATCH_TIME=y
CONFIG_NETFILTER_XT_MATCH_U32=y
# CONFIG_IP_SET is not set
CONFIG_IP_VS=y
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12

#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
# CONFIG_IP_VS_PROTO_ESP is not set
CONFIG_IP_VS_PROTO_AH=y
CONFIG_IP_VS_PROTO_SCTP=y

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=y
# CONFIG_IP_VS_WRR is not set
CONFIG_IP_VS_LC=y
# CONFIG_IP_VS_WLC is not set
# CONFIG_IP_VS_LBLC is not set
# CONFIG_IP_VS_LBLCR is not set
# CONFIG_IP_VS_DH is not set
# CONFIG_IP_VS_SH is not set
# CONFIG_IP_VS_SED is not set
# CONFIG_IP_VS_NQ is not set

#
# IPVS SH scheduler
#
CONFIG_IP_VS_SH_TAB_BITS=8

#
# IPVS application helper
#

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_AH=y
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_RPFILTER is not set
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_ECN=y
# CONFIG_IP_NF_TARGET_TTL is not set
CONFIG_IP_NF_RAW=y
# CONFIG_IP_NF_SECURITY is not set
# CONFIG_IP_NF_ARPTABLES is not set
CONFIG_BRIDGE_NF_EBTABLES=y
# CONFIG_BRIDGE_EBT_BROUTE is not set
CONFIG_BRIDGE_EBT_T_FILTER=y
CONFIG_BRIDGE_EBT_T_NAT=y
CONFIG_BRIDGE_EBT_802_3=y
# CONFIG_BRIDGE_EBT_AMONG is not set
CONFIG_BRIDGE_EBT_ARP=y
CONFIG_BRIDGE_EBT_IP=y
CONFIG_BRIDGE_EBT_LIMIT=y
# CONFIG_BRIDGE_EBT_MARK is not set
# CONFIG_BRIDGE_EBT_PKTTYPE is not set
CONFIG_BRIDGE_EBT_STP=y
CONFIG_BRIDGE_EBT_VLAN=y
# CONFIG_BRIDGE_EBT_ARPREPLY is not set
CONFIG_BRIDGE_EBT_DNAT=y
# CONFIG_BRIDGE_EBT_MARK_T is not set
CONFIG_BRIDGE_EBT_REDIRECT=y
# CONFIG_BRIDGE_EBT_SNAT is not set
# CONFIG_BRIDGE_EBT_LOG is not set
# CONFIG_BRIDGE_EBT_ULOG is not set
# CONFIG_BRIDGE_EBT_NFLOG is not set
# CONFIG_IP_DCCP is not set
CONFIG_IP_SCTP=y
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5 is not set
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1 is not set
CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE=y
CONFIG_SCTP_COOKIE_HMAC_MD5=y
CONFIG_SCTP_COOKIE_HMAC_SHA1=y
# CONFIG_RDS is not set
CONFIG_TIPC=y
CONFIG_TIPC_PORTS=8191
CONFIG_ATM=y
# CONFIG_ATM_CLIP is not set
CONFIG_ATM_LANE=y
# CONFIG_ATM_MPOA is not set
# CONFIG_ATM_BR2684 is not set
CONFIG_L2TP=y
CONFIG_L2TP_DEBUGFS=y
CONFIG_L2TP_V3=y
# CONFIG_L2TP_IP is not set
# CONFIG_L2TP_ETH is not set
CONFIG_STP=y
CONFIG_GARP=y
CONFIG_BRIDGE=y
# CONFIG_BRIDGE_IGMP_SNOOPING is not set
CONFIG_HAVE_NET_DSA=y
CONFIG_NET_DSA=y
CONFIG_NET_DSA_TAG_DSA=y
CONFIG_NET_DSA_TAG_EDSA=y
CONFIG_NET_DSA_TAG_TRAILER=y
CONFIG_VLAN_8021Q=y
CONFIG_VLAN_8021Q_GVRP=y
# CONFIG_DECNET is not set
CONFIG_LLC=y
CONFIG_LLC2=y
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
CONFIG_X25=y
CONFIG_LAPB=y
# CONFIG_WAN_ROUTER is not set
CONFIG_PHONET=y
CONFIG_IEEE802154=y
CONFIG_MAC802154=y
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_ATM=y
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_MULTIQ=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFB=y
CONFIG_NET_SCH_SFQ=y
# CONFIG_NET_SCH_TEQL is not set
CONFIG_NET_SCH_TBF=y
# CONFIG_NET_SCH_GRED is not set
CONFIG_NET_SCH_DSMARK=y
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_DRR=y
CONFIG_NET_SCH_MQPRIO=y
# CONFIG_NET_SCH_CHOKE is not set
CONFIG_NET_SCH_QFQ=y
CONFIG_NET_SCH_CODEL=y
CONFIG_NET_SCH_FQ_CODEL=y
CONFIG_NET_SCH_INGRESS=y
CONFIG_NET_SCH_PLUG=y

#
# Classification
#
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_ROUTE4=y
# CONFIG_NET_CLS_FW is not set
# CONFIG_NET_CLS_U32 is not set
CONFIG_NET_CLS_RSVP=y
CONFIG_NET_CLS_RSVP6=y
CONFIG_NET_CLS_FLOW=y
# CONFIG_NET_EMATCH is not set
CONFIG_NET_CLS_ACT=y
# CONFIG_NET_ACT_POLICE is not set
CONFIG_NET_ACT_GACT=y
CONFIG_GACT_PROB=y
# CONFIG_NET_ACT_MIRRED is not set
CONFIG_NET_ACT_IPT=y
CONFIG_NET_ACT_NAT=y
# CONFIG_NET_ACT_PEDIT is not set
CONFIG_NET_ACT_SIMP=y
CONFIG_NET_ACT_SKBEDIT=y
CONFIG_NET_ACT_CSUM=y
CONFIG_NET_SCH_FIFO=y
CONFIG_DCB=y
CONFIG_DNS_RESOLVER=y
CONFIG_BATMAN_ADV=y
CONFIG_BATMAN_ADV_BLA=y
# CONFIG_BATMAN_ADV_DAT is not set
CONFIG_BATMAN_ADV_DEBUG=y
# CONFIG_OPENVSWITCH is not set
CONFIG_BQL=y

#
# Network testing
#
CONFIG_NET_PKTGEN=y
CONFIG_NET_DROP_MONITOR=y
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
CONFIG_AX25=y
CONFIG_AX25_DAMA_SLAVE=y
# CONFIG_NETROM is not set
# CONFIG_ROSE is not set

#
# AX.25 network device drivers
#
CONFIG_MKISS=y
CONFIG_6PACK=y
CONFIG_BPQETHER=y
# CONFIG_DMASCC is not set
# CONFIG_SCC is not set
# CONFIG_BAYCOM_SER_FDX is not set
# CONFIG_BAYCOM_SER_HDX is not set
CONFIG_BAYCOM_PAR=y
# CONFIG_BAYCOM_EPP is not set
CONFIG_YAM=y
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
CONFIG_BT=y
# CONFIG_BT_RFCOMM is not set
# CONFIG_BT_BNEP is not set
# CONFIG_BT_HIDP is not set

#
# Bluetooth device drivers
#
CONFIG_BT_HCIBTUSB=y
CONFIG_BT_HCIUART=y
# CONFIG_BT_HCIUART_H4 is not set
# CONFIG_BT_HCIUART_BCSP is not set
CONFIG_BT_HCIUART_ATH3K=y
CONFIG_BT_HCIUART_LL=y
# CONFIG_BT_HCIUART_3WIRE is not set
CONFIG_BT_HCIBCM203X=y
CONFIG_BT_HCIBPA10X=y
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIVHCI is not set
# CONFIG_BT_MRVL is not set
# CONFIG_BT_ATH3K is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_INPUT=y
CONFIG_RFKILL_REGULATOR=y
CONFIG_NET_9P=y
CONFIG_NET_9P_VIRTIO=y
CONFIG_NET_9P_DEBUG=y
# CONFIG_CAIF is not set
CONFIG_CEPH_LIB=y
# CONFIG_CEPH_LIB_PRETTYDEBUG is not set
CONFIG_CEPH_LIB_USE_DNS_RESOLVER=y
# CONFIG_NFC is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
# CONFIG_DEVTMPFS is not set
# CONFIG_STANDALONE is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_DEBUG_DRIVER=y
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_MMIO=y
CONFIG_REGMAP_IRQ=y
CONFIG_DMA_SHARED_BUFFER=y
# CONFIG_CMA is not set

#
# Bus devices
#
CONFIG_CONNECTOR=y
# CONFIG_PROC_EVENTS is not set
CONFIG_MTD=y
CONFIG_MTD_REDBOOT_PARTS=y
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1
# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set
CONFIG_MTD_REDBOOT_PARTS_READONLY=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_OF_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
# CONFIG_MTD_CHAR is not set
CONFIG_HAVE_MTD_OTP=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_FTL=y
CONFIG_NFTL=y
CONFIG_NFTL_RW=y
# CONFIG_INFTL is not set
CONFIG_RFD_FTL=y
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
# CONFIG_MTD_CFI_NOSWAP is not set
CONFIG_MTD_CFI_BE_BYTE_SWAP=y
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
# CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_2 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_4 is not set
CONFIG_MTD_MAP_BANK_WIDTH_8=y
CONFIG_MTD_MAP_BANK_WIDTH_16=y
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
# CONFIG_MTD_CFI_I1 is not set
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_OTP=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_RAM=y
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_COMPAT=y
CONFIG_MTD_PHYSMAP_START=0x8000000
CONFIG_MTD_PHYSMAP_LEN=0
CONFIG_MTD_PHYSMAP_BANKWIDTH=2
CONFIG_MTD_PHYSMAP_OF=y
# CONFIG_MTD_SC520CDP is not set
CONFIG_MTD_NETSC520=y
# CONFIG_MTD_TS5500 is not set
# CONFIG_MTD_SBC_GXX is not set
# CONFIG_MTD_AMD76XROM is not set
CONFIG_MTD_ICHXROM=y
CONFIG_MTD_ESB2ROM=y
CONFIG_MTD_CK804XROM=y
# CONFIG_MTD_SCB2_FLASH is not set
CONFIG_MTD_NETtel=y
CONFIG_MTD_L440GX=y
# CONFIG_MTD_PCI is not set
# CONFIG_MTD_GPIO_ADDR is not set
# CONFIG_MTD_INTEL_VR_NOR is not set
CONFIG_MTD_PLATRAM=y
CONFIG_MTD_LATCH_ADDR=y

#
# Self-contained MTD device drivers
#
CONFIG_MTD_PMC551=y
CONFIG_MTD_PMC551_BUGFIX=y
CONFIG_MTD_PMC551_DEBUG=y
# CONFIG_MTD_SLRAM is not set
CONFIG_MTD_PHRAM=y
# CONFIG_MTD_MTDRAM is not set
CONFIG_MTD_BLOCK2MTD=y

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
# CONFIG_MTD_NAND is not set
CONFIG_MTD_ONENAND=y
CONFIG_MTD_ONENAND_VERIFY_WRITE=y
CONFIG_MTD_ONENAND_GENERIC=y
# CONFIG_MTD_ONENAND_OTP is not set
# CONFIG_MTD_ONENAND_2X_PROGRAM is not set
# CONFIG_MTD_ONENAND_SIM is not set

#
# LPDDR flash memory drivers
#
CONFIG_MTD_LPDDR=y
CONFIG_MTD_QINFO_PROBE=y
# CONFIG_MTD_UBI is not set
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
# CONFIG_PROC_DEVICETREE is not set
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_PROMTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
CONFIG_OF_PCI=y
CONFIG_OF_PCI_IRQ=y
CONFIG_OF_MTD=y
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_AX88796=y
# CONFIG_PARPORT_1284 is not set
CONFIG_PARPORT_NOT_PC=y
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
# CONFIG_ISAPNP is not set
CONFIG_PNPBIOS=y
# CONFIG_PNPBIOS_PROC_FS is not set
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_XD=y
CONFIG_PARIDE=y

#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=y
CONFIG_PARIDE_PCD=y
CONFIG_PARIDE_PF=y
# CONFIG_PARIDE_PT is not set
# CONFIG_PARIDE_PG is not set

#
# Parallel IDE protocol modules
#
CONFIG_PARIDE_ATEN=y
# CONFIG_PARIDE_BPCK is not set
# CONFIG_PARIDE_BPCK6 is not set
# CONFIG_PARIDE_COMM is not set
# CONFIG_PARIDE_DSTR is not set
CONFIG_PARIDE_FIT2=y
CONFIG_PARIDE_FIT3=y
# CONFIG_PARIDE_EPAT is not set
# CONFIG_PARIDE_EPIA is not set
# CONFIG_PARIDE_FRIQ is not set
# CONFIG_PARIDE_FRPW is not set
# CONFIG_PARIDE_KBIC is not set
CONFIG_PARIDE_KTTI=y
# CONFIG_PARIDE_ON20 is not set
CONFIG_PARIDE_ON26=y
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
CONFIG_BLK_CPQ_DA=y
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_NVME=y
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
CONFIG_ATA_OVER_ETH=y
CONFIG_VIRTIO_BLK=y
CONFIG_BLK_DEV_HD=y
CONFIG_BLK_DEV_RBD=y

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
CONFIG_IBM_ASM=y
# CONFIG_PHANTOM is not set
CONFIG_INTEL_MID_PTI=y
# CONFIG_SGI_IOC4 is not set
CONFIG_TIFM_CORE=y
CONFIG_TIFM_7XX1=y
# CONFIG_ICS932S401 is not set
CONFIG_ENCLOSURE_SERVICES=y
# CONFIG_CS5535_MFGPT is not set
# CONFIG_HP_ILO is not set
CONFIG_APDS9802ALS=y
CONFIG_ISL29003=y
# CONFIG_ISL29020 is not set
CONFIG_SENSORS_TSL2550=y
CONFIG_SENSORS_BH1780=y
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
CONFIG_HMC6352=y
CONFIG_DS1682=y
CONFIG_VMWARE_BALLOON=y
CONFIG_BMP085=y
CONFIG_BMP085_I2C=y
# CONFIG_PCH_PHUB is not set
CONFIG_USB_SWITCH_FSA9480=y
CONFIG_C2PORT=y
# CONFIG_C2PORT_DURAMAR_2150 is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
CONFIG_EEPROM_MAX6875=y
CONFIG_EEPROM_93CX6=y
CONFIG_CB710_CORE=y
CONFIG_CB710_DEBUG=y
CONFIG_CB710_DEBUG_ASSUMPTIONS=y

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
CONFIG_ALTERA_STAPL=y
# CONFIG_INTEL_MEI is not set
CONFIG_HAVE_IDE=y
CONFIG_IDE=y

#
# Please see Documentation/ide/ide.txt for help/info on IDE drives
#
CONFIG_IDE_XFER_MODE=y
CONFIG_IDE_TIMINGS=y
CONFIG_IDE_ATAPI=y
CONFIG_IDE_LEGACY=y
CONFIG_BLK_DEV_IDE_SATA=y
# CONFIG_IDE_GD is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEACPI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_PROC_FS=y

#
# IDE chipset support/bugfixes
#
# CONFIG_IDE_GENERIC is not set
# CONFIG_BLK_DEV_PLATFORM is not set
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPNP=y
CONFIG_BLK_DEV_IDEDMA_SFF=y

#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_OPTI621=y
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_AEC62XX is not set
CONFIG_BLK_DEV_ALI15X3=y
CONFIG_BLK_DEV_AMD74XX=y
# CONFIG_BLK_DEV_ATIIXP is not set
CONFIG_BLK_DEV_CMD64X=y
# CONFIG_BLK_DEV_TRIFLEX is not set
CONFIG_BLK_DEV_CS5520=y
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
CONFIG_BLK_DEV_CS5536=y
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
CONFIG_BLK_DEV_SC1200=y
# CONFIG_BLK_DEV_PIIX is not set
CONFIG_BLK_DEV_IT8172=y
CONFIG_BLK_DEV_IT8213=y
CONFIG_BLK_DEV_IT821X=y
CONFIG_BLK_DEV_NS87415=y
CONFIG_BLK_DEV_PDC202XX_OLD=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_BLK_DEV_SVWKS=y
CONFIG_BLK_DEV_SIIMAGE=y
CONFIG_BLK_DEV_SIS5513=y
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
CONFIG_BLK_DEV_TC86C001=y

#
# Other IDE chipsets support
#

#
# Note: most of these also require special kernel boot parameters
#
CONFIG_BLK_DEV_4DRIVES=y
# CONFIG_BLK_DEV_ALI14XX is not set
# CONFIG_BLK_DEV_DTC2278 is not set
# CONFIG_BLK_DEV_HT6560B is not set
# CONFIG_BLK_DEV_QD65XX is not set
CONFIG_BLK_DEV_UMC8672=y
CONFIG_BLK_DEV_IDEDMA=y

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
CONFIG_RAID_ATTRS=y
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_NETLINK=y
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
CONFIG_CHR_DEV_SCH=y
# CONFIG_SCSI_ENCLOSURE is not set
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
CONFIG_SCSI_SCAN_ASYNC=y

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
# CONFIG_SCSI_ISCSI_ATTRS is not set
CONFIG_SCSI_SAS_ATTRS=y
CONFIG_SCSI_SAS_LIBSAS=y
# CONFIG_SCSI_SAS_ATA is not set
CONFIG_SCSI_SAS_HOST_SMP=y
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_DH is not set
CONFIG_SCSI_OSD_INITIATOR=y
# CONFIG_SCSI_OSD_ULD is not set
CONFIG_SCSI_OSD_DPRINT_SENSE=1
# CONFIG_SCSI_OSD_DEBUG is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
# CONFIG_ATA_VERBOSE_ERROR is not set
# CONFIG_ATA_ACPI is not set
# CONFIG_SATA_PMP is not set

#
# Controllers with non-SFF native interface
#
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_AHCI_PLATFORM is not set
# CONFIG_SATA_INIC162X is not set
CONFIG_SATA_ACARD_AHCI=y
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
CONFIG_PDC_ADMA=y
CONFIG_SATA_QSTOR=y
CONFIG_SATA_SX4=y
CONFIG_ATA_BMDMA=y

#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=y
CONFIG_SATA_HIGHBANK=y
# CONFIG_SATA_MV is not set
CONFIG_SATA_NV=y
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SIL is not set
CONFIG_SATA_SIS=y
# CONFIG_SATA_SVW is not set
# CONFIG_SATA_ULI is not set
CONFIG_SATA_VIA=y
CONFIG_SATA_VITESSE=y

#
# PATA SFF controllers with BMDMA
#
CONFIG_PATA_ALI=y
# CONFIG_PATA_AMD is not set
CONFIG_PATA_ARTOP=y
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_CMD64X is not set
CONFIG_PATA_CS5520=y
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CS5536 is not set
CONFIG_PATA_CYPRESS=y
CONFIG_PATA_EFAR=y
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
CONFIG_PATA_HPT3X3=y
CONFIG_PATA_HPT3X3_DMA=y
CONFIG_PATA_IT8213=y
CONFIG_PATA_IT821X=y
# CONFIG_PATA_JMICRON is not set
CONFIG_PATA_MARVELL=y
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
CONFIG_PATA_NS87415=y
# CONFIG_PATA_OLDPIIX is not set
CONFIG_PATA_OPTIDMA=y
# CONFIG_PATA_PDC2027X is not set
CONFIG_PATA_PDC_OLD=y
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_SC1200 is not set
CONFIG_PATA_SCH=y
CONFIG_PATA_SERVERWORKS=y
CONFIG_PATA_SIL680=y
CONFIG_PATA_SIS=y
CONFIG_PATA_TOSHIBA=y
CONFIG_PATA_TRIFLEX=y
CONFIG_PATA_VIA=y
CONFIG_PATA_WINBOND=y

#
# PIO-only SFF controllers
#
CONFIG_PATA_CMD640_PCI=y
CONFIG_PATA_MPIIX=y
# CONFIG_PATA_NS87410 is not set
CONFIG_PATA_OPTI=y
CONFIG_PATA_PLATFORM=y
# CONFIG_PATA_OF_PLATFORM is not set
CONFIG_PATA_QDI=y
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_WINBOND_VLB is not set

#
# Generic fallback / legacy drivers
#
CONFIG_ATA_GENERIC=y
CONFIG_PATA_LEGACY=y
# CONFIG_MD is not set
CONFIG_TARGET_CORE=y
# CONFIG_TCM_IBLOCK is not set
# CONFIG_TCM_FILEIO is not set
# CONFIG_TCM_PSCSI is not set
# CONFIG_LOOPBACK_TARGET is not set
CONFIG_ISCSI_TARGET=y
# CONFIG_SBP_TARGET is not set
CONFIG_FUSION=y
# CONFIG_FUSION_SPI is not set
CONFIG_FUSION_FC=y
CONFIG_FUSION_SAS=y
CONFIG_FUSION_MAX_SGE=128
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set
CONFIG_FUSION_LOGGING=y

#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=y
CONFIG_FIREWIRE_OHCI=y
CONFIG_FIREWIRE_SBP2=y
CONFIG_FIREWIRE_NET=y
# CONFIG_FIREWIRE_NOSY is not set
CONFIG_I2O=y
# CONFIG_I2O_LCT_NOTIFY_ON_CHANGES is not set
# CONFIG_I2O_EXT_ADAPTEC is not set
# CONFIG_I2O_CONFIG is not set
CONFIG_I2O_BUS=y
CONFIG_I2O_BLOCK=y
CONFIG_I2O_SCSI=y
# CONFIG_I2O_PROC is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
CONFIG_DUMMY=y
CONFIG_EQUALIZER=y
CONFIG_NET_FC=y
CONFIG_MII=y
CONFIG_IFB=y
CONFIG_NET_TEAM=y
# CONFIG_NET_TEAM_MODE_BROADCAST is not set
CONFIG_NET_TEAM_MODE_ROUNDROBIN=y
# CONFIG_NET_TEAM_MODE_ACTIVEBACKUP is not set
CONFIG_NET_TEAM_MODE_LOADBALANCE=y
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
CONFIG_NETCONSOLE=y
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_TUN is not set
# CONFIG_VETH is not set
CONFIG_VIRTIO_NET=y
# CONFIG_ARCNET is not set
CONFIG_ATM_DRIVERS=y
# CONFIG_ATM_DUMMY is not set
# CONFIG_ATM_TCP is not set
CONFIG_ATM_LANAI=y
CONFIG_ATM_ENI=y
# CONFIG_ATM_ENI_DEBUG is not set
CONFIG_ATM_ENI_TUNE_BURST=y
CONFIG_ATM_ENI_BURST_TX_16W=y
CONFIG_ATM_ENI_BURST_TX_8W=y
CONFIG_ATM_ENI_BURST_TX_4W=y
# CONFIG_ATM_ENI_BURST_TX_2W is not set
# CONFIG_ATM_ENI_BURST_RX_16W is not set
# CONFIG_ATM_ENI_BURST_RX_8W is not set
CONFIG_ATM_ENI_BURST_RX_4W=y
CONFIG_ATM_ENI_BURST_RX_2W=y
# CONFIG_ATM_FIRESTREAM is not set
CONFIG_ATM_ZATM=y
# CONFIG_ATM_ZATM_DEBUG is not set
CONFIG_ATM_NICSTAR=y
# CONFIG_ATM_NICSTAR_USE_SUNI is not set
# CONFIG_ATM_NICSTAR_USE_IDT77105 is not set
# CONFIG_ATM_IDT77252 is not set
# CONFIG_ATM_AMBASSADOR is not set
CONFIG_ATM_HORIZON=y
CONFIG_ATM_HORIZON_DEBUG=y
# CONFIG_ATM_IA is not set
CONFIG_ATM_FORE200E=y
CONFIG_ATM_FORE200E_USE_TASKLET=y
CONFIG_ATM_FORE200E_TX_RETRY=16
CONFIG_ATM_FORE200E_DEBUG=0
# CONFIG_ATM_HE is not set
CONFIG_ATM_SOLOS=y

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
CONFIG_NET_DSA_MV88E6XXX=y
CONFIG_NET_DSA_MV88E6060=y
CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y
CONFIG_NET_DSA_MV88E6131=y
CONFIG_NET_DSA_MV88E6123_61_65=y
CONFIG_ETHERNET=y
CONFIG_MDIO=y
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
# CONFIG_VORTEX is not set
# CONFIG_TYPHOON is not set
# CONFIG_NET_VENDOR_ADAPTEC is not set
# CONFIG_NET_VENDOR_ALTEON is not set
# CONFIG_NET_VENDOR_AMD is not set
CONFIG_NET_VENDOR_ATHEROS=y
CONFIG_ATL2=y
CONFIG_ATL1=y
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_NET_CADENCE is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
CONFIG_BNX2=y
# CONFIG_CNIC is not set
# CONFIG_TIGON3 is not set
CONFIG_BNX2X=y
CONFIG_NET_VENDOR_BROCADE=y
# CONFIG_BNA is not set
CONFIG_NET_CALXEDA_XGMAC=y
# CONFIG_NET_VENDOR_CHELSIO is not set
# CONFIG_NET_VENDOR_CIRRUS is not set
CONFIG_NET_VENDOR_CISCO=y
CONFIG_ENIC=y
CONFIG_DNET=y
CONFIG_NET_VENDOR_DEC=y
# CONFIG_EWRK3 is not set
CONFIG_NET_TULIP=y
CONFIG_DE2104X=y
CONFIG_DE2104X_DSL=0
CONFIG_TULIP=y
CONFIG_TULIP_MWI=y
CONFIG_TULIP_MMIO=y
# CONFIG_TULIP_NAPI is not set
CONFIG_DE4X5=y
# CONFIG_WINBOND_840 is not set
CONFIG_DM9102=y
# CONFIG_ULI526X is not set
CONFIG_NET_VENDOR_DLINK=y
CONFIG_DE600=y
CONFIG_DE620=y
# CONFIG_DL2K is not set
# CONFIG_SUNDANCE is not set
# CONFIG_NET_VENDOR_EMULEX is not set
CONFIG_NET_VENDOR_EXAR=y
# CONFIG_S2IO is not set
CONFIG_VXGE=y
CONFIG_VXGE_DEBUG_TRACE_ALL=y
CONFIG_NET_VENDOR_FUJITSU=y
# CONFIG_AT1700 is not set
CONFIG_ETH16I=y
CONFIG_NET_VENDOR_HP=y
# CONFIG_HP100 is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_IP1000 is not set
# CONFIG_JME is not set
# CONFIG_NET_VENDOR_MARVELL is not set
CONFIG_NET_VENDOR_MELLANOX=y
# CONFIG_MLX4_EN is not set
# CONFIG_MLX4_CORE is not set
CONFIG_NET_VENDOR_MICREL=y
CONFIG_KS8851_MLL=y
CONFIG_KSZ884X_PCI=y
CONFIG_NET_VENDOR_MYRI=y
CONFIG_MYRI10GE=y
CONFIG_FEALNX=y
# CONFIG_NET_VENDOR_NATSEMI is not set
CONFIG_NET_VENDOR_NVIDIA=y
# CONFIG_FORCEDETH is not set
CONFIG_NET_VENDOR_OKI=y
CONFIG_PCH_GBE=y
CONFIG_ETHOC=y
CONFIG_NET_PACKET_ENGINE=y
CONFIG_HAMACHI=y
# CONFIG_YELLOWFIN is not set
CONFIG_NET_VENDOR_QLOGIC=y
CONFIG_QLA3XXX=y
# CONFIG_QLCNIC is not set
CONFIG_QLGE=y
# CONFIG_NETXEN_NIC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_NET_VENDOR_REALTEK is not set
CONFIG_NET_VENDOR_RDC=y
# CONFIG_R6040 is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SILAN is not set
CONFIG_NET_VENDOR_SIS=y
# CONFIG_SIS900 is not set
CONFIG_SIS190=y
# CONFIG_SFC is not set
# CONFIG_NET_VENDOR_SMSC is not set
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_SUN is not set
CONFIG_NET_VENDOR_TEHUTI=y
# CONFIG_TEHUTI is not set
# CONFIG_NET_VENDOR_TI is not set
# CONFIG_NET_VENDOR_VIA is not set
# CONFIG_NET_VENDOR_WIZNET is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
CONFIG_AT803X_PHY=y
# CONFIG_AMD_PHY is not set
CONFIG_MARVELL_PHY=y
CONFIG_DAVICOM_PHY=y
CONFIG_QSEMI_PHY=y
# CONFIG_LXT_PHY is not set
CONFIG_CICADA_PHY=y
CONFIG_VITESSE_PHY=y
CONFIG_SMSC_PHY=y
CONFIG_BROADCOM_PHY=y
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
CONFIG_NATIONAL_PHY=y
CONFIG_STE10XP=y
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
CONFIG_FIXED_PHY=y
# CONFIG_MDIO_BITBANG is not set
CONFIG_MDIO_BUS_MUX=y
CONFIG_MDIO_BUS_MUX_GPIO=y
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_PLIP is not set
CONFIG_PPP=y
CONFIG_PPP_BSDCOMP=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_MPPE=y
CONFIG_PPP_MULTILINK=y
# CONFIG_PPPOATM is not set
# CONFIG_PPPOE is not set
# CONFIG_PPTP is not set
# CONFIG_PPPOL2TP is not set
# CONFIG_PPP_ASYNC is not set
# CONFIG_PPP_SYNC_TTY is not set
CONFIG_SLIP=y
CONFIG_SLHC=y
CONFIG_SLIP_COMPRESSED=y
# CONFIG_SLIP_SMART is not set
# CONFIG_SLIP_MODE_SLIP6 is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
CONFIG_USB_KAWETH=y
CONFIG_USB_PEGASUS=y
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
CONFIG_USB_HSO=y
CONFIG_USB_CDC_PHONET=y
# CONFIG_USB_IPHETH is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
CONFIG_IEEE802154_DRIVERS=y
CONFIG_IEEE802154_FAKEHARD=y
# CONFIG_IEEE802154_FAKELB is not set
CONFIG_VMXNET3=y
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=y
CONFIG_INPUT_SPARSEKMAP=y
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
CONFIG_INPUT_JOYDEV=y
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
CONFIG_INPUT_MOUSE=y
# CONFIG_MOUSE_PS2 is not set
CONFIG_MOUSE_SERIAL=y
CONFIG_MOUSE_APPLETOUCH=y
# CONFIG_MOUSE_BCM5974 is not set
CONFIG_MOUSE_INPORT=y
CONFIG_MOUSE_ATIXL=y
CONFIG_MOUSE_LOGIBM=y
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_GPIO is not set
CONFIG_MOUSE_SYNAPTICS_I2C=y
# CONFIG_MOUSE_SYNAPTICS_USB is not set
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
CONFIG_JOYSTICK_GRIP_MP=y
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
CONFIG_JOYSTICK_SIDEWINDER=y
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
CONFIG_JOYSTICK_WARRIOR=y
CONFIG_JOYSTICK_MAGELLAN=y
CONFIG_JOYSTICK_SPACEORB=y
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
CONFIG_JOYSTICK_ZHENHUA=y
CONFIG_JOYSTICK_DB9=y
CONFIG_JOYSTICK_GAMECON=y
# CONFIG_JOYSTICK_TURBOGRAFX is not set
CONFIG_JOYSTICK_AS5011=y
CONFIG_JOYSTICK_JOYDUMP=y
CONFIG_JOYSTICK_XPAD=y
# CONFIG_JOYSTICK_XPAD_FF is not set
# CONFIG_JOYSTICK_XPAD_LEDS is not set
# CONFIG_JOYSTICK_WALKERA0701 is not set
CONFIG_INPUT_TABLET=y
# CONFIG_TABLET_USB_ACECAD is not set
# CONFIG_TABLET_USB_AIPTEK is not set
# CONFIG_TABLET_USB_GTCO is not set
# CONFIG_TABLET_USB_HANWANG is not set
CONFIG_TABLET_USB_KBTAB=y
CONFIG_TABLET_USB_WACOM=y
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_CT82C710=y
CONFIG_SERIO_PARKBD=y
CONFIG_SERIO_PCIPS2=y
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=y
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
CONFIG_GAMEPORT=y
# CONFIG_GAMEPORT_NS558 is not set
CONFIG_GAMEPORT_L4=y
CONFIG_GAMEPORT_EMU10K1=y
# CONFIG_GAMEPORT_FM801 is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
# CONFIG_VT_CONSOLE is not set
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_UNIX98_PTYS is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_NOZOMI=y
CONFIG_N_GSM=y
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_PNP is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
# CONFIG_SERIAL_8250_PCI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_DW is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_KGDB_NMI is not set
# CONFIG_SERIAL_MFD_HSU is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
CONFIG_SERIAL_JSM=y
# CONFIG_SERIAL_OF_PLATFORM is not set
# CONFIG_SERIAL_SCCNXP is not set
CONFIG_SERIAL_TIMBERDALE=y
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_PCH_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_PRINTER is not set
CONFIG_PPDEV=y
CONFIG_HVC_DRIVER=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_IPMI_HANDLER=y
# CONFIG_IPMI_PANIC_EVENT is not set
# CONFIG_IPMI_DEVICE_INTERFACE is not set
CONFIG_IPMI_SI=y
# CONFIG_IPMI_WATCHDOG is not set
CONFIG_IPMI_POWEROFF=y
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_DTLK is not set
CONFIG_R3964=y
# CONFIG_APPLICOM is not set
CONFIG_SONYPI=y
CONFIG_MWAVE=y
# CONFIG_PC8736x_GPIO is not set
CONFIG_NSC_GPIO=y
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=256
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
CONFIG_HANGCHECK_TIMER=y
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=y
CONFIG_TCG_TIS_I2C_INFINEON=y
CONFIG_TCG_NSC=y
CONFIG_TCG_ATMEL=y
CONFIG_TCG_INFINEON=y
CONFIG_TELCLOCK=y
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_COMPAT is not set
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_SMBUS=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
CONFIG_I2C_ALI1535=y
CONFIG_I2C_ALI1563=y
# CONFIG_I2C_ALI15X3 is not set
CONFIG_I2C_AMD756=y
CONFIG_I2C_AMD756_S4882=y
CONFIG_I2C_AMD8111=y
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_ISCH is not set
CONFIG_I2C_PIIX4=y
CONFIG_I2C_NFORCE2=y
# CONFIG_I2C_NFORCE2_S4985 is not set
# CONFIG_I2C_SIS5595 is not set
CONFIG_I2C_SIS630=y
CONFIG_I2C_SIS96X=y
# CONFIG_I2C_VIA is not set
CONFIG_I2C_VIAPRO=y

#
# ACPI drivers
#
# CONFIG_I2C_SCMI is not set

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
CONFIG_I2C_CBUS_GPIO=y
CONFIG_I2C_DESIGNWARE_CORE=y
CONFIG_I2C_DESIGNWARE_PCI=y
# CONFIG_I2C_EG20T is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_INTEL_MID is not set
CONFIG_I2C_OCORES=y
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
CONFIG_I2C_PARPORT=y
CONFIG_I2C_PARPORT_LIGHT=y
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_TINY_USB=y
# CONFIG_I2C_VIPERBOARD is not set

#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_ELEKTOR=y
# CONFIG_I2C_PCA_ISA is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_DEBUG_CORE is not set
CONFIG_I2C_DEBUG_ALGO=y
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set
CONFIG_HSI=y
CONFIG_HSI_BOARDINFO=y

#
# HSI clients
#
CONFIG_HSI_CHAR=y

#
# PPS support
#
CONFIG_PPS=y
CONFIG_PPS_DEBUG=y

#
# PPS clients support
#
CONFIG_PPS_CLIENT_KTIMER=y
CONFIG_PPS_CLIENT_LDISC=y
# CONFIG_PPS_CLIENT_PARPORT is not set
# CONFIG_PPS_CLIENT_GPIO is not set

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_PTP_1588_CLOCK_PCH=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
CONFIG_GPIO_ACPI=y
# CONFIG_DEBUG_GPIO is not set
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_DA9052=y

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_IT8761E is not set
# CONFIG_GPIO_TS5500 is not set
CONFIG_GPIO_SCH=y
# CONFIG_GPIO_ICH is not set
CONFIG_GPIO_VX855=y

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
CONFIG_GPIO_MAX732X=y
CONFIG_GPIO_MAX732X_IRQ=y
# CONFIG_GPIO_PCA953X is not set
CONFIG_GPIO_PCF857X=y
CONFIG_GPIO_RC5T583=y
CONFIG_GPIO_SX150X=y
# CONFIG_GPIO_TPS65912 is not set
CONFIG_GPIO_TWL4030=y
# CONFIG_GPIO_TWL6040 is not set
CONFIG_GPIO_WM831X=y
# CONFIG_GPIO_WM8350 is not set
# CONFIG_GPIO_WM8994 is not set
CONFIG_GPIO_ADP5520=y
CONFIG_GPIO_ADP5588=y
CONFIG_GPIO_ADP5588_IRQ=y
# CONFIG_GPIO_ADNP is not set

#
# PCI GPIO expanders:
#
# CONFIG_GPIO_CS5535 is not set
CONFIG_GPIO_BT8XX=y
# CONFIG_GPIO_AMD8111 is not set
CONFIG_GPIO_LANGWELL=y
# CONFIG_GPIO_PCH is not set
# CONFIG_GPIO_ML_IOH is not set
# CONFIG_GPIO_SODAVILLE is not set
# CONFIG_GPIO_RDC321X is not set

#
# SPI GPIO expanders:
#
CONFIG_GPIO_MCP23S08=y

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#
# CONFIG_GPIO_JANZ_TTL is not set
# CONFIG_GPIO_TPS6586X is not set

#
# USB GPIO expanders:
#
# CONFIG_GPIO_VIPERBOARD is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
CONFIG_GENERIC_ADC_BATTERY=y
CONFIG_MAX8925_POWER=y
# CONFIG_WM831X_BACKUP is not set
# CONFIG_WM831X_POWER is not set
CONFIG_WM8350_POWER=y
CONFIG_TEST_POWER=y
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_OLPC is not set
CONFIG_BATTERY_SBS=y
# CONFIG_BATTERY_BQ27x00 is not set
CONFIG_BATTERY_DA9052=y
CONFIG_BATTERY_MAX17040=y
CONFIG_BATTERY_MAX17042=y
# CONFIG_CHARGER_MAX8903 is not set
CONFIG_CHARGER_TWL4030=y
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_GPIO is not set
# CONFIG_CHARGER_MANAGER is not set
CONFIG_CHARGER_MAX8997=y
# CONFIG_CHARGER_MAX8998 is not set
# CONFIG_CHARGER_BQ2415X is not set
CONFIG_CHARGER_SMB347=y
# CONFIG_POWER_RESET is not set
CONFIG_POWER_AVS=y
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
CONFIG_HWMON_DEBUG_CHIP=y

#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
CONFIG_SENSORS_AD7414=y
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
CONFIG_SENSORS_ADM1025=y
# CONFIG_SENSORS_ADM1026 is not set
CONFIG_SENSORS_ADM1029=y
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7410 is not set
CONFIG_SENSORS_ADT7411=y
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
CONFIG_SENSORS_ADT7475=y
CONFIG_SENSORS_ASC7621=y
CONFIG_SENSORS_K8TEMP=y
# CONFIG_SENSORS_K10TEMP is not set
# CONFIG_SENSORS_FAM15H_POWER is not set
# CONFIG_SENSORS_ASB100 is not set
CONFIG_SENSORS_ATXP1=y
# CONFIG_SENSORS_DS620 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_DA9052_ADC is not set
CONFIG_SENSORS_I5K_AMB=y
# CONFIG_SENSORS_F71805F is not set
CONFIG_SENSORS_F71882FG=y
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHMD is not set
CONFIG_SENSORS_G760A=y
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_GPIO_FAN is not set
CONFIG_SENSORS_HIH6130=y
CONFIG_SENSORS_CORETEMP=y
CONFIG_SENSORS_IBMAEM=y
# CONFIG_SENSORS_IBMPEX is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_JC42 is not set
CONFIG_SENSORS_LINEAGE=y
# CONFIG_SENSORS_LM63 is not set
CONFIG_SENSORS_LM73=y
# CONFIG_SENSORS_LM75 is not set
CONFIG_SENSORS_LM77=y
CONFIG_SENSORS_LM78=y
CONFIG_SENSORS_LM80=y
CONFIG_SENSORS_LM83=y
CONFIG_SENSORS_LM85=y
CONFIG_SENSORS_LM87=y
CONFIG_SENSORS_LM90=y
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
CONFIG_SENSORS_LTC4245=y
# CONFIG_SENSORS_LTC4261 is not set
CONFIG_SENSORS_LM95241=y
CONFIG_SENSORS_LM95245=y
# CONFIG_SENSORS_MAX16065 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX1668 is not set
# CONFIG_SENSORS_MAX197 is not set
CONFIG_SENSORS_MAX6639=y
# CONFIG_SENSORS_MAX6642 is not set
# CONFIG_SENSORS_MAX6650 is not set
CONFIG_SENSORS_MCP3021=y
# CONFIG_SENSORS_NTC_THERMISTOR is not set
CONFIG_SENSORS_PC87360=y
CONFIG_SENSORS_PC87427=y
CONFIG_SENSORS_PCF8591=y
CONFIG_PMBUS=y
# CONFIG_SENSORS_PMBUS is not set
# CONFIG_SENSORS_ADM1275 is not set
# CONFIG_SENSORS_LM25066 is not set
# CONFIG_SENSORS_LTC2978 is not set
# CONFIG_SENSORS_MAX16064 is not set
# CONFIG_SENSORS_MAX34440 is not set
CONFIG_SENSORS_MAX8688=y
# CONFIG_SENSORS_UCD9000 is not set
# CONFIG_SENSORS_UCD9200 is not set
CONFIG_SENSORS_ZL6100=y
CONFIG_SENSORS_SHT15=y
CONFIG_SENSORS_SHT21=y
# CONFIG_SENSORS_SIS5595 is not set
CONFIG_SENSORS_SMM665=y
CONFIG_SENSORS_DME1737=y
CONFIG_SENSORS_EMC1403=y
CONFIG_SENSORS_EMC2103=y
# CONFIG_SENSORS_EMC6W201 is not set
CONFIG_SENSORS_SMSC47M1=y
# CONFIG_SENSORS_SMSC47M192 is not set
CONFIG_SENSORS_SMSC47B397=y
CONFIG_SENSORS_SCH56XX_COMMON=y
CONFIG_SENSORS_SCH5627=y
CONFIG_SENSORS_SCH5636=y
CONFIG_SENSORS_ADS1015=y
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_INA2XX is not set
# CONFIG_SENSORS_THMC50 is not set
CONFIG_SENSORS_TMP102=y
# CONFIG_SENSORS_TMP401 is not set
CONFIG_SENSORS_TMP421=y
CONFIG_SENSORS_VIA_CPUTEMP=y
# CONFIG_SENSORS_VIA686A is not set
CONFIG_SENSORS_VT1211=y
CONFIG_SENSORS_VT8231=y
# CONFIG_SENSORS_W83781D is not set
CONFIG_SENSORS_W83791D=y
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
CONFIG_SENSORS_W83L785TS=y
CONFIG_SENSORS_W83L786NG=y
CONFIG_SENSORS_W83627HF=y
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_SENSORS_WM831X=y
# CONFIG_SENSORS_WM8350 is not set
CONFIG_SENSORS_APPLESMC=y

#
# ACPI drivers
#
CONFIG_SENSORS_ACPI_POWER=y
# CONFIG_SENSORS_ATK0110 is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
CONFIG_FAIR_SHARE=y
CONFIG_STEP_WISE=y
# CONFIG_USER_SPACE is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
CONFIG_WATCHDOG_NOWAYOUT=y

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_DA9052_WATCHDOG is not set
CONFIG_WM831X_WATCHDOG=y
# CONFIG_WM8350_WATCHDOG is not set
# CONFIG_TWL4030_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
CONFIG_ADVANTECH_WDT=y
CONFIG_ALIM1535_WDT=y
# CONFIG_ALIM7101_WDT is not set
CONFIG_F71808E_WDT=y
# CONFIG_SP5100_TCO is not set
CONFIG_SC520_WDT=y
# CONFIG_SBC_FITPC2_WATCHDOG is not set
CONFIG_EUROTECH_WDT=y
CONFIG_IB700_WDT=y
CONFIG_IBMASR=y
CONFIG_WAFER_WDT=y
# CONFIG_I6300ESB_WDT is not set
CONFIG_IE6XX_WDT=y
# CONFIG_ITCO_WDT is not set
# CONFIG_IT8712F_WDT is not set
# CONFIG_IT87_WDT is not set
CONFIG_HP_WATCHDOG=y
# CONFIG_HPWDT_NMI_DECODING is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_NV_TCO is not set
CONFIG_60XX_WDT=y
# CONFIG_SBC8360_WDT is not set
CONFIG_SBC7240_WDT=y
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC_SCH311X_WDT is not set
CONFIG_SMSC37B787_WDT=y
# CONFIG_VIA_WDT is not set
CONFIG_W83627HF_WDT=y
# CONFIG_W83697HF_WDT is not set
CONFIG_W83697UG_WDT=y
CONFIG_W83877F_WDT=y
# CONFIG_W83977F_WDT is not set
CONFIG_MACHZ_WDT=y
CONFIG_SBC_EPX_C3_WATCHDOG=y

#
# ISA-based Watchdog Cards
#
# CONFIG_PCWATCHDOG is not set
# CONFIG_MIXCOMWD is not set
# CONFIG_WDT is not set

#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=y
CONFIG_WDTPCI=y

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
CONFIG_BCMA=y
CONFIG_BCMA_HOST_PCI_POSSIBLE=y
# CONFIG_BCMA_HOST_PCI is not set
# CONFIG_BCMA_DRIVER_GMAC_CMN is not set
CONFIG_BCMA_DRIVER_GPIO=y
# CONFIG_BCMA_DEBUG is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_88PM800 is not set
CONFIG_MFD_88PM805=y
CONFIG_MFD_SM501=y
# CONFIG_MFD_SM501_GPIO is not set
# CONFIG_MFD_RTSX_PCI is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_LM3533 is not set
CONFIG_TPS6105X=y
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65217 is not set
CONFIG_MFD_TPS6586X=y
# CONFIG_MFD_TPS65910 is not set
CONFIG_MFD_TPS65912=y
CONFIG_MFD_TPS65912_I2C=y
# CONFIG_MFD_TPS80031 is not set
CONFIG_TWL4030_CORE=y
# CONFIG_TWL4030_MADC is not set
# CONFIG_MFD_TWL4030_AUDIO is not set
CONFIG_TWL6040_CORE=y
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
CONFIG_MFD_SMSC=y
# CONFIG_PMIC_DA903X is not set
CONFIG_PMIC_DA9052=y
CONFIG_MFD_DA9052_I2C=y
# CONFIG_MFD_DA9055 is not set
CONFIG_PMIC_ADP5520=y
# CONFIG_MFD_LP8788 is not set
CONFIG_MFD_MAX77686=y
CONFIG_MFD_MAX77693=y
# CONFIG_MFD_MAX8907 is not set
CONFIG_MFD_MAX8925=y
CONFIG_MFD_MAX8997=y
CONFIG_MFD_MAX8998=y
CONFIG_MFD_SEC_CORE=y
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_WM8400 is not set
CONFIG_MFD_WM831X=y
CONFIG_MFD_WM831X_I2C=y
CONFIG_MFD_WM8350=y
CONFIG_MFD_WM8350_I2C=y
CONFIG_MFD_WM8994=y
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_ABX500_CORE is not set
CONFIG_MFD_CS5535=y
# CONFIG_MFD_TIMBERDALE is not set
CONFIG_LPC_SCH=y
CONFIG_LPC_ICH=y
CONFIG_MFD_RDC321X=y
CONFIG_MFD_JANZ_CMODIO=y
CONFIG_MFD_VX855=y
# CONFIG_MFD_WL1273_CORE is not set
CONFIG_MFD_TPS65090=y
CONFIG_MFD_AAT2870_CORE=y
CONFIG_MFD_RC5T583=y
CONFIG_MFD_SYSCON=y
CONFIG_MFD_PALMAS=y
CONFIG_MFD_VIPERBOARD=y
CONFIG_MFD_RETU=y
# CONFIG_MFD_AS3711 is not set
CONFIG_REGULATOR=y
CONFIG_REGULATOR_DEBUG=y
# CONFIG_REGULATOR_DUMMY is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_VIRTUAL_CONSUMER=y
CONFIG_REGULATOR_USERSPACE_CONSUMER=y
CONFIG_REGULATOR_GPIO=y
# CONFIG_REGULATOR_AD5398 is not set
CONFIG_REGULATOR_AAT2870=y
# CONFIG_REGULATOR_DA9052 is not set
CONFIG_REGULATOR_FAN53555=y
# CONFIG_REGULATOR_ANATOP is not set
# CONFIG_REGULATOR_ISL6271A is not set
CONFIG_REGULATOR_MAX1586=y
CONFIG_REGULATOR_MAX8649=y
CONFIG_REGULATOR_MAX8660=y
CONFIG_REGULATOR_MAX8925=y
# CONFIG_REGULATOR_MAX8952 is not set
CONFIG_REGULATOR_MAX8973=y
CONFIG_REGULATOR_MAX8997=y
CONFIG_REGULATOR_MAX8998=y
# CONFIG_REGULATOR_MAX77686 is not set
CONFIG_REGULATOR_LP3971=y
# CONFIG_REGULATOR_LP3972 is not set
CONFIG_REGULATOR_LP872X=y
CONFIG_REGULATOR_RC5T583=y
# CONFIG_REGULATOR_S2MPS11 is not set
# CONFIG_REGULATOR_S5M8767 is not set
CONFIG_REGULATOR_PALMAS=y
CONFIG_REGULATOR_TPS51632=y
CONFIG_REGULATOR_TPS6105X=y
# CONFIG_REGULATOR_TPS62360 is not set
# CONFIG_REGULATOR_TPS65023 is not set
# CONFIG_REGULATOR_TPS6507X is not set
# CONFIG_REGULATOR_TPS65090 is not set
# CONFIG_REGULATOR_TPS6586X is not set
# CONFIG_REGULATOR_TPS65912 is not set
# CONFIG_REGULATOR_TWL4030 is not set
# CONFIG_REGULATOR_WM831X is not set
# CONFIG_REGULATOR_WM8350 is not set
CONFIG_REGULATOR_WM8994=y
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_ALI=y
CONFIG_AGP_ATI=y
# CONFIG_AGP_AMD is not set
CONFIG_AGP_AMD64=y
# CONFIG_AGP_INTEL is not set
CONFIG_AGP_NVIDIA=y
CONFIG_AGP_SIS=y
CONFIG_AGP_SWORKS=y
CONFIG_AGP_VIA=y
CONFIG_AGP_EFFICEON=y
# CONFIG_VGA_ARB is not set
# CONFIG_VGA_SWITCHEROO is not set
CONFIG_DRM=y
CONFIG_DRM_USB=y
CONFIG_DRM_KMS_HELPER=y
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_DRM_TTM=y
# CONFIG_DRM_TDFX is not set
CONFIG_DRM_R128=y
# CONFIG_DRM_RADEON is not set
CONFIG_DRM_NOUVEAU=y
CONFIG_NOUVEAU_DEBUG=5
CONFIG_NOUVEAU_DEBUG_DEFAULT=3
# CONFIG_DRM_NOUVEAU_BACKLIGHT is not set

#
# I2C encoder or helper chips
#
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
CONFIG_DRM_MGA=y
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_DRM_VMWGFX is not set
# CONFIG_DRM_GMA500 is not set
CONFIG_DRM_UDL=y
CONFIG_DRM_AST=y
CONFIG_DRM_MGAG200=y
# CONFIG_DRM_CIRRUS_QEMU is not set
CONFIG_STUB_POULSBO=y
CONFIG_VGASTATE=y
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_DDC=y
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
# CONFIG_FB_WMT_GE_ROPS is not set
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_HECUBA=y
CONFIG_FB_SVGALIB=y
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
CONFIG_FB_CIRRUS=y
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
CONFIG_FB_IMSTT=y
CONFIG_FB_VGA16=y
# CONFIG_FB_UVESA is not set
# CONFIG_FB_VESA is not set
CONFIG_FB_N411=y
CONFIG_FB_HGA=y
CONFIG_FB_S1D13XXX=y
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
CONFIG_FB_I740=y
CONFIG_FB_LE80578=y
# CONFIG_FB_CARILLO_RANCH is not set
CONFIG_FB_MATROX=y
# CONFIG_FB_MATROX_MILLENIUM is not set
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G=y
CONFIG_FB_MATROX_I2C=y
CONFIG_FB_MATROX_MAVEN=y
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
# CONFIG_FB_RADEON_BACKLIGHT is not set
CONFIG_FB_RADEON_DEBUG=y
CONFIG_FB_ATY128=y
CONFIG_FB_ATY128_BACKLIGHT=y
CONFIG_FB_ATY=y
CONFIG_FB_ATY_CT=y
# CONFIG_FB_ATY_GENERIC_LCD is not set
# CONFIG_FB_ATY_GX is not set
# CONFIG_FB_ATY_BACKLIGHT is not set
CONFIG_FB_S3=y
CONFIG_FB_S3_DDC=y
CONFIG_FB_SAVAGE=y
CONFIG_FB_SAVAGE_I2C=y
CONFIG_FB_SAVAGE_ACCEL=y
# CONFIG_FB_SIS is not set
CONFIG_FB_VIA=y
# CONFIG_FB_VIA_DIRECT_PROCFS is not set
# CONFIG_FB_VIA_X_COMPATIBILITY is not set
# CONFIG_FB_NEOMAGIC is not set
CONFIG_FB_KYRO=y
CONFIG_FB_3DFX=y
CONFIG_FB_3DFX_ACCEL=y
# CONFIG_FB_3DFX_I2C is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
CONFIG_FB_TRIDENT=y
CONFIG_FB_ARK=y
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
CONFIG_FB_TMIO=y
# CONFIG_FB_TMIO_ACCELL is not set
CONFIG_FB_SM501=y
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
CONFIG_FB_VIRTUAL=y
CONFIG_FB_METRONOME=y
CONFIG_FB_MB862XX=y
CONFIG_FB_MB862XX_PCI_GDC=y
CONFIG_FB_MB862XX_I2C=y
CONFIG_FB_BROADSHEET=y
CONFIG_FB_AUO_K190X=y
# CONFIG_FB_AUO_K1900 is not set
# CONFIG_FB_AUO_K1901 is not set
CONFIG_EXYNOS_VIDEO=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
# CONFIG_BACKLIGHT_PWM is not set
CONFIG_BACKLIGHT_DA9052=y
# CONFIG_BACKLIGHT_MAX8925 is not set
CONFIG_BACKLIGHT_APPLE=y
# CONFIG_BACKLIGHT_SAHARA is not set
CONFIG_BACKLIGHT_WM831X=y
CONFIG_BACKLIGHT_ADP5520=y
# CONFIG_BACKLIGHT_ADP8860 is not set
CONFIG_BACKLIGHT_ADP8870=y
# CONFIG_BACKLIGHT_AAT2870 is not set
# CONFIG_BACKLIGHT_LM3630 is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LP855X is not set
CONFIG_BACKLIGHT_PANDORA=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_MDA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
CONFIG_FONT_8x16=y
# CONFIG_FONT_6x11 is not set
CONFIG_FONT_7x14=y
# CONFIG_FONT_PEARL_8x8 is not set
CONFIG_FONT_ACORN_8x8=y
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
CONFIG_FONT_SUN12x22=y
CONFIG_FONT_10x18=y
# CONFIG_LOGO is not set
# CONFIG_FB_SSD1307 is not set
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=y
CONFIG_HID_BATTERY_STRENGTH=y
# CONFIG_HIDRAW is not set
CONFIG_UHID=y
# CONFIG_HID_GENERIC is not set

#
# Special HID drivers
#

#
# USB HID support
#
# CONFIG_USB_HID is not set
CONFIG_HID_PID=y

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
CONFIG_USB_MOUSE=y

#
# I2C HID support
#
CONFIG_I2C_HID=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_OTG_WHITELIST=y
CONFIG_USB_OTG_BLACKLIST_HUB=y
CONFIG_USB_MON=y
CONFIG_USB_WUSB=y
CONFIG_USB_WUSB_CBAF=y
# CONFIG_USB_WUSB_CBAF_DEBUG is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_XHCI_HCD=y
# CONFIG_USB_XHCI_HCD_DEBUGGING is not set
# CONFIG_USB_EHCI_HCD is not set
CONFIG_USB_OXU210HP_HCD=y
CONFIG_USB_ISP116X_HCD=y
CONFIG_USB_ISP1760_HCD=y
CONFIG_USB_ISP1362_HCD=y
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
CONFIG_USB_R8A66597_HCD=y
# CONFIG_USB_WHCI_HCD is not set
# CONFIG_USB_HWA_HCD is not set
CONFIG_USB_HCD_BCMA=y
CONFIG_USB_CHIPIDEA=y
# CONFIG_USB_CHIPIDEA_DEBUG is not set

#
# USB Device Class drivers
#
CONFIG_USB_ACM=y
CONFIG_USB_PRINTER=y
CONFIG_USB_WDM=y
CONFIG_USB_TMC=y

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
CONFIG_USB_STORAGE_DEBUG=y
CONFIG_USB_STORAGE_REALTEK=y
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
# CONFIG_USB_STORAGE_ISD200 is not set
CONFIG_USB_STORAGE_USBAT=y
CONFIG_USB_STORAGE_SDDR09=y
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
CONFIG_USB_STORAGE_ALAUDA=y
CONFIG_USB_STORAGE_ONETOUCH=y
CONFIG_USB_STORAGE_KARMA=y
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_STORAGE_ENE_UB6250 is not set

#
# USB Imaging devices
#
CONFIG_USB_MDC800=y
CONFIG_USB_MICROTEK=y

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y
# CONFIG_USB_SERIAL_GENERIC is not set
CONFIG_USB_SERIAL_AIRCABLE=y
# CONFIG_USB_SERIAL_ARK3116 is not set
CONFIG_USB_SERIAL_BELKIN=y
# CONFIG_USB_SERIAL_CH341 is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=y
# CONFIG_USB_SERIAL_CP210X is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
CONFIG_USB_SERIAL_FTDI_SIO=y
CONFIG_USB_SERIAL_FUNSOFT=y
CONFIG_USB_SERIAL_VISOR=y
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
CONFIG_USB_SERIAL_EDGEPORT=y
CONFIG_USB_SERIAL_EDGEPORT_TI=y
CONFIG_USB_SERIAL_F81232=y
CONFIG_USB_SERIAL_GARMIN=y
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_IUU is not set
CONFIG_USB_SERIAL_KEYSPAN_PDA=y
CONFIG_USB_SERIAL_KEYSPAN=y
# CONFIG_USB_SERIAL_KEYSPAN_MPR is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
# CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
# CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19QW is not set
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
# CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA49WLC is not set
# CONFIG_USB_SERIAL_KLSI is not set
CONFIG_USB_SERIAL_KOBIL_SCT=y
# CONFIG_USB_SERIAL_MCT_U232 is not set
CONFIG_USB_SERIAL_METRO=y
# CONFIG_USB_SERIAL_MOS7720 is not set
CONFIG_USB_SERIAL_MOS7840=y
# CONFIG_USB_SERIAL_MOTOROLA is not set
CONFIG_USB_SERIAL_NAVMAN=y
CONFIG_USB_SERIAL_PL2303=y
CONFIG_USB_SERIAL_OTI6858=y
# CONFIG_USB_SERIAL_QCAUX is not set
# CONFIG_USB_SERIAL_QUALCOMM is not set
CONFIG_USB_SERIAL_SPCP8X5=y
# CONFIG_USB_SERIAL_HP4X is not set
CONFIG_USB_SERIAL_SAFE=y
# CONFIG_USB_SERIAL_SAFE_PADDED is not set
CONFIG_USB_SERIAL_SIEMENS_MPI=y
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
CONFIG_USB_SERIAL_SYMBOL=y
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
CONFIG_USB_SERIAL_XIRCOM=y
CONFIG_USB_SERIAL_WWAN=y
CONFIG_USB_SERIAL_OPTION=y
CONFIG_USB_SERIAL_OMNINET=y
# CONFIG_USB_SERIAL_OPTICON is not set
CONFIG_USB_SERIAL_VIVOPAY_SERIAL=y
CONFIG_USB_SERIAL_ZIO=y
# CONFIG_USB_SERIAL_ZTE is not set
# CONFIG_USB_SERIAL_SSU100 is not set
CONFIG_USB_SERIAL_QT2=y
# CONFIG_USB_SERIAL_DEBUG is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
CONFIG_USB_EMI26=y
# CONFIG_USB_ADUTUX is not set
CONFIG_USB_SEVSEG=y
CONFIG_USB_RIO500=y
CONFIG_USB_LEGOTOWER=y
# CONFIG_USB_LCD is not set
CONFIG_USB_LED=y
# CONFIG_USB_CYPRESS_CY7C63 is not set
CONFIG_USB_CYTHERM=y
CONFIG_USB_IDMOUSE=y
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
CONFIG_USB_LD=y
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=y
CONFIG_USB_ISIGHTFW=y
CONFIG_USB_YUREX=y
CONFIG_USB_EZUSB_FX2=y

#
# USB Physical Layer drivers
#
CONFIG_USB_ISP1301=y
# CONFIG_USB_RCAR_PHY is not set
CONFIG_USB_ATM=y
# CONFIG_USB_SPEEDTOUCH is not set
# CONFIG_USB_CXACRU is not set
CONFIG_USB_UEAGLEATM=y
CONFIG_USB_XUSBATM=y
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_NOP_USB_XCEIV is not set
CONFIG_UWB=y
# CONFIG_UWB_HWA is not set
CONFIG_UWB_WHCI=y
# CONFIG_MMC is not set
CONFIG_MEMSTICK=y
# CONFIG_MEMSTICK_DEBUG is not set

#
# MemoryStick drivers
#
CONFIG_MEMSTICK_UNSAFE_RESUME=y
CONFIG_MSPRO_BLOCK=y

#
# MemoryStick Host Controller Drivers
#
# CONFIG_MEMSTICK_TIFM_MS is not set
CONFIG_MEMSTICK_JMICRON_38X=y
# CONFIG_MEMSTICK_R592 is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
CONFIG_LEDS_LM3530=y
# CONFIG_LEDS_LM3642 is not set
CONFIG_LEDS_PCA9532=y
# CONFIG_LEDS_PCA9532_GPIO is not set
# CONFIG_LEDS_GPIO is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
# CONFIG_LEDS_WM831X_STATUS is not set
# CONFIG_LEDS_WM8350 is not set
# CONFIG_LEDS_DA9052 is not set
CONFIG_LEDS_REGULATOR=y
CONFIG_LEDS_BD2802=y
CONFIG_LEDS_INTEL_SS4200=y
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_ADP5520 is not set
# CONFIG_LEDS_DELL_NETBOOKS is not set
CONFIG_LEDS_TCA6507=y
# CONFIG_LEDS_MAX8997 is not set
CONFIG_LEDS_LM355x=y
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set
# CONFIG_LEDS_TRIGGERS is not set

#
# LED Triggers
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
CONFIG_EDAC_LEGACY_SYSFS=y
# CONFIG_EDAC_DEBUG is not set
# CONFIG_EDAC_MM_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
CONFIG_RTC_DEBUG=y

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
# CONFIG_RTC_INTF_PROC is not set
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_DRV_TEST=y

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
CONFIG_RTC_DRV_DS1374=y
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_MAX8925 is not set
CONFIG_RTC_DRV_MAX8998=y
CONFIG_RTC_DRV_RS5C372=y
CONFIG_RTC_DRV_ISL1208=y
# CONFIG_RTC_DRV_ISL12022 is not set
CONFIG_RTC_DRV_X1205=y
CONFIG_RTC_DRV_PCF8523=y
CONFIG_RTC_DRV_PCF8563=y
CONFIG_RTC_DRV_PCF8583=y
CONFIG_RTC_DRV_M41T80=y
# CONFIG_RTC_DRV_M41T80_WDT is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_TWL4030 is not set
# CONFIG_RTC_DRV_RC5T583 is not set
# CONFIG_RTC_DRV_S35390A is not set
CONFIG_RTC_DRV_FM3130=y
CONFIG_RTC_DRV_RX8581=y
CONFIG_RTC_DRV_RX8025=y
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
CONFIG_RTC_DRV_DS1286=y
CONFIG_RTC_DRV_DS1511=y
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
CONFIG_RTC_DRV_DA9052=y
# CONFIG_RTC_DRV_STK17TA8 is not set
CONFIG_RTC_DRV_M48T86=y
CONFIG_RTC_DRV_M48T35=y
CONFIG_RTC_DRV_M48T59=y
CONFIG_RTC_DRV_MSM6242=y
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
CONFIG_RTC_DRV_V3020=y
CONFIG_RTC_DRV_DS2404=y
CONFIG_RTC_DRV_WM831X=y
# CONFIG_RTC_DRV_WM8350 is not set

#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_SNVS is not set
# CONFIG_DMADEVICES is not set
CONFIG_AUXDISPLAY=y
CONFIG_KS0108=y
CONFIG_KS0108_PORT=0x378
CONFIG_KS0108_DELAY=2
# CONFIG_CFAG12864B is not set
CONFIG_UIO=y
CONFIG_UIO_CIF=y
# CONFIG_UIO_PDRV is not set
CONFIG_UIO_PDRV_GENIRQ=y
CONFIG_UIO_DMEM_GENIRQ=y
# CONFIG_UIO_AEC is not set
# CONFIG_UIO_SERCOS3 is not set
CONFIG_UIO_PCI_GENERIC=y
# CONFIG_UIO_NETX is not set
# CONFIG_VFIO is not set
CONFIG_VIRTIO=y

#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=y
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_VIRTIO_MMIO=y
# CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_HYPERV is not set
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACER_WMI is not set
CONFIG_ACERHDF=y
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_DELL_WMI is not set
CONFIG_DELL_WMI_AIO=y
CONFIG_FUJITSU_LAPTOP=y
CONFIG_FUJITSU_LAPTOP_DEBUG=y
CONFIG_FUJITSU_TABLET=y
CONFIG_AMILO_RFKILL=y
# CONFIG_TC1100_WMI is not set
# CONFIG_HP_ACCEL is not set
# CONFIG_HP_WMI is not set
CONFIG_MSI_LAPTOP=y
CONFIG_PANASONIC_LAPTOP=y
# CONFIG_COMPAL_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_IDEAPAD_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_SENSORS_HDAPS is not set
CONFIG_ACPI_WMI=y
# CONFIG_MSI_WMI is not set
CONFIG_TOPSTAR_LAPTOP=y
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_TOSHIBA_BT_RFKILL is not set
CONFIG_ACPI_CMPC=y
CONFIG_INTEL_IPS=y
CONFIG_IBM_RTL=y
CONFIG_XO1_RFKILL=y
CONFIG_XO15_EBOOK=y
CONFIG_SAMSUNG_LAPTOP=y
CONFIG_MXM_WMI=y
CONFIG_INTEL_OAKTRAIL=y
CONFIG_SAMSUNG_Q10=y
CONFIG_APPLE_GMUX=y

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_I8253=y
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y
CONFIG_DMAR_TABLE=y
CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y

#
# Remoteproc drivers (EXPERIMENTAL)
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers (EXPERIMENTAL)
#
CONFIG_VIRT_DRIVERS=y
CONFIG_PM_DEVFREQ=y

#
# DEVFREQ Governors
#
CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=y
# CONFIG_DEVFREQ_GOV_PERFORMANCE is not set
# CONFIG_DEVFREQ_GOV_POWERSAVE is not set
# CONFIG_DEVFREQ_GOV_USERSPACE is not set

#
# DEVFREQ Drivers
#
CONFIG_EXTCON=y

#
# Extcon Device Drivers
#
CONFIG_EXTCON_GPIO=y
CONFIG_EXTCON_ADC_JACK=y
CONFIG_EXTCON_MAX77693=y
CONFIG_EXTCON_MAX8997=y
CONFIG_MEMORY=y
CONFIG_IIO=y
CONFIG_IIO_BUFFER=y
# CONFIG_IIO_BUFFER_CB is not set
CONFIG_IIO_KFIFO_BUF=y
CONFIG_IIO_TRIGGER=y
CONFIG_IIO_CONSUMERS_PER_TRIGGER=2

#
# Accelerometers
#

#
# Analog to digital converters
#
CONFIG_MAX1363=y
# CONFIG_TI_ADC081C is not set
CONFIG_VIPERBOARD_ADC=y

#
# Amplifiers
#

#
# Hid Sensor IIO Common
#

#
# Digital to analog converters
#
CONFIG_AD5064=y
CONFIG_AD5380=y
CONFIG_AD5446=y
CONFIG_MAX517=y
# CONFIG_MCP4725 is not set

#
# Frequency Synthesizers DDS/PLL
#

#
# Clock Generator/Distribution
#

#
# Phase-Locked Loop (PLL) frequency synthesizers
#

#
# Digital gyroscope sensors
#

#
# Inertial measurement units
#

#
# Light sensors
#
# CONFIG_ADJD_S311 is not set
CONFIG_VCNL4000=y

#
# Magnetometer sensors
#
CONFIG_VME_BUS=y

#
# VME Bridge Drivers
#
# CONFIG_VME_CA91CX42 is not set
# CONFIG_VME_TSI148 is not set

#
# VME Board Drivers
#
# CONFIG_VMIVME_7805 is not set

#
# VME Device Drivers
#
CONFIG_PWM=y
CONFIG_PWM_TWL=y
CONFIG_PWM_TWL_LED=y
CONFIG_IPACK_BUS=y
CONFIG_BOARD_TPCI200=y
CONFIG_SERIAL_IPOCTAL=y

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_DMIID is not set
CONFIG_DMI_SYSFS=y
# CONFIG_ISCSI_IBFT_FIND is not set
# CONFIG_GOOGLE_FIRMWARE is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT23=y
# CONFIG_EXT4_FS_POSIX_ACL is not set
# CONFIG_EXT4_FS_SECURITY is not set
CONFIG_EXT4_DEBUG=y
CONFIG_JBD2=y
CONFIG_JBD2_DEBUG=y
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
# CONFIG_XFS_POSIX_ACL is not set
# CONFIG_XFS_RT is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_QUOTACTL=y
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=y
# CONFIG_CUSE is not set

#
# Caches
#
CONFIG_FSCACHE=y
# CONFIG_FSCACHE_STATS is not set
CONFIG_FSCACHE_HISTOGRAM=y
CONFIG_FSCACHE_DEBUG=y
# CONFIG_FSCACHE_OBJECT_LIST is not set
# CONFIG_CACHEFILES is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
# CONFIG_VFAT_FS is not set
CONFIG_FAT_DEFAULT_CODEPAGE=437
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
# CONFIG_PROC_VMCORE is not set
CONFIG_PROC_SYSCTL=y
# CONFIG_PROC_PAGE_MONITOR is not set
CONFIG_SYSFS=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
CONFIG_HFSPLUS_FS=y
# CONFIG_BEFS_FS is not set
CONFIG_BFS_FS=y
CONFIG_EFS_FS=y
# CONFIG_JFFS2_FS is not set
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
CONFIG_VXFS_FS=y
CONFIG_MINIX_FS=y
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
CONFIG_QNX6FS_FS=y
# CONFIG_QNX6FS_DEBUG is not set
# CONFIG_ROMFS_FS is not set
CONFIG_PSTORE=y
CONFIG_PSTORE_CONSOLE=y
# CONFIG_PSTORE_FTRACE is not set
CONFIG_PSTORE_RAM=y
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
# CONFIG_NFS_FS is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
CONFIG_NFSD_V4=y
CONFIG_NFSD_FAULT_INJECTION=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
CONFIG_SUNRPC_DEBUG=y
# CONFIG_CEPH_FS is not set
CONFIG_CIFS=y
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
# CONFIG_CIFS_UPCALL is not set
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_ACL is not set
# CONFIG_CIFS_DEBUG is not set
CONFIG_CIFS_DFS_UPCALL=y
CONFIG_CIFS_SMB2=y
# CONFIG_CIFS_FSCACHE is not set
CONFIG_NCP_FS=y
CONFIG_NCPFS_PACKET_SIGNING=y
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
CONFIG_NCPFS_NFS_NS=y
# CONFIG_NCPFS_OS2_NS is not set
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_9P_FS=y
CONFIG_9P_FSCACHE=y
CONFIG_9P_FS_POSIX_ACL=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
CONFIG_NLS_CODEPAGE_860=y
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
CONFIG_NLS_CODEPAGE_863=y
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
CONFIG_NLS_CODEPAGE_932=y
CONFIG_NLS_CODEPAGE_949=y
CONFIG_NLS_CODEPAGE_874=y
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
CONFIG_NLS_CODEPAGE_1251=y
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
CONFIG_NLS_ISO8859_5=y
CONFIG_NLS_ISO8859_6=y
# CONFIG_NLS_ISO8859_7 is not set
CONFIG_NLS_ISO8859_9=y
# CONFIG_NLS_ISO8859_13 is not set
CONFIG_NLS_ISO8859_14=y
# CONFIG_NLS_ISO8859_15 is not set
CONFIG_NLS_KOI8_R=y
CONFIG_NLS_KOI8_U=y
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
CONFIG_NLS_MAC_ICELAND=y
CONFIG_NLS_MAC_INUIT=y
CONFIG_NLS_MAC_ROMANIAN=y
# CONFIG_NLS_MAC_TURKISH is not set
CONFIG_NLS_UTF8=y
CONFIG_DLM=y
# CONFIG_DLM_DEBUG is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_READABLE_ASM=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=1
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
CONFIG_SLUB_DEBUG_ON=y
CONFIG_SLUB_STATS=y
CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400
# CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
# CONFIG_PROVE_RCU is not set
# CONFIG_PROVE_RCU_DELAY is not set
CONFIG_SPARSE_RCU_POINTER=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
CONFIG_DEBUG_LOCKDEP=y
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_KOBJECT=y
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_INFO is not set
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_VM_RB=y
CONFIG_DEBUG_VIRTUAL=y
CONFIG_DEBUG_WRITECOUNT=y
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
CONFIG_TEST_LIST_SORT=y
# CONFIG_DEBUG_SG is not set
CONFIG_DEBUG_NOTIFIERS=y
CONFIG_DEBUG_CREDENTIALS=y
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
CONFIG_RCU_TORTURE_TEST=y
# CONFIG_RCU_TORTURE_TEST_RUNNABLE is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
CONFIG_DEBUG_BLOCK_EXT_DEVT=y
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_LKDTM=y
CONFIG_NOTIFIER_ERROR_INJECTION=y
# CONFIG_PM_NOTIFIER_ERROR_INJECT is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_WANT_PAGE_DEBUG_FLAGS=y
CONFIG_PAGE_GUARD=y
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_EVENT_POWER_TRACING_DEPRECATED=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SCHED_TRACER is not set
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACE_BRANCH_PROFILING=y
# CONFIG_BRANCH_PROFILE_NONE is not set
CONFIG_PROFILE_ANNOTATED_BRANCHES=y
# CONFIG_PROFILE_ALL_BRANCHES is not set
CONFIG_TRACING_BRANCHES=y
CONFIG_BRANCH_TRACER=y
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
# CONFIG_UPROBE_EVENT is not set
# CONFIG_PROBE_EVENTS is not set
CONFIG_DYNAMIC_FTRACE=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
CONFIG_FIREWIRE_OHCI_REMOTE_DMA=y
CONFIG_BUILD_DOCSRC=y
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
CONFIG_SAMPLES=y
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_KGDB_TESTS=y
# CONFIG_KGDB_TESTS_ON_BOOT is not set
CONFIG_KGDB_LOW_LEVEL_TRAP=y
CONFIG_KGDB_KDB=y
# CONFIG_KDB_KEYBOARD is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_TEST_KSTRTOX=y
CONFIG_STRICT_DEVMEM=y
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
CONFIG_X86_PTDUMP=y
# CONFIG_DEBUG_RODATA is not set
# CONFIG_DOUBLEFAULT is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
# CONFIG_IO_DELAY_0XED is not set
CONFIG_IO_DELAY_UDELAY=y
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=2
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_TRUSTED_KEYS is not set
CONFIG_ENCRYPTED_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
# CONFIG_SECURITY_NETWORK is not set
# CONFIG_SECURITY_PATH is not set
# CONFIG_INTEL_TXT is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set
CONFIG_INTEGRITY=y
CONFIG_INTEGRITY_SIGNATURE=y
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
# CONFIG_IMA_APPRAISE is not set
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
CONFIG_CRYPTO_GF128MUL=y
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=y
# CONFIG_CRYPTO_AUTHENC is not set
CONFIG_CRYPTO_ABLK_HELPER_X86=y
CONFIG_CRYPTO_GLUE_HELPER_X86=y

#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=y
# CONFIG_CRYPTO_GCM is not set
CONFIG_CRYPTO_SEQIV=y

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=y
CONFIG_CRYPTO_CTS=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=y
# CONFIG_CRYPTO_PCBC is not set
CONFIG_CRYPTO_XTS=y

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=y
# CONFIG_CRYPTO_GHASH is not set
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_RMD128=y
CONFIG_CRYPTO_RMD160=y
CONFIG_CRYPTO_RMD256=y
CONFIG_CRYPTO_RMD320=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_TGR192=y
CONFIG_CRYPTO_WP512=y

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_586=y
CONFIG_CRYPTO_AES_NI_INTEL=y
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_KHAZAD=y
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_586 is not set
CONFIG_CRYPTO_SEED=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_SERPENT_SSE2_586=y
CONFIG_CRYPTO_TEA=y
# CONFIG_CRYPTO_TWOFISH is not set
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_TWOFISH_586=y

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
# CONFIG_KVM is not set
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_PERCPU_RWSEM=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_REED_SOLOMON=y
CONFIG_REED_SOLOMON_ENC8=y
CONFIG_REED_SOLOMON_DEC8=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=y
CONFIG_TEXTSEARCH_BM=y
CONFIG_TEXTSEARCH_FSM=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
CONFIG_CLZ_TAB=y
# CONFIG_CORDIC is not set
CONFIG_DDR=y
CONFIG_MPILIB=y
CONFIG_SIGNATURE=y

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2012-12-26 22:00           ` David Rientjes
@ 2012-12-26 22:19             ` David Woodhouse
  2012-12-27  1:52               ` David Rientjes
  2012-12-26 22:30             ` Jesper Juhl
                               ` (2 subsequent siblings)
  3 siblings, 1 reply; 65+ messages in thread
From: David Woodhouse @ 2012-12-26 22:19 UTC (permalink / raw)
  To: David Rientjes
  Cc: Ingo Molnar, H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel,
	linux-tip-commits

[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]

On Wed, 2012-12-26 at 14:00 -0800, David Rientjes wrote:
> Umm, you're saying that is legitimate for "make randconfig" done on a 
> 32-bit machine to generate 64-bit configurations?  The resulting kernel 
> cannot be booted. 

It has never been expected that a 'randconfig' kernel would actually
boot. And yes, it's absolutely legitimate for 'make randconfig' on a
32-bit machine to generate 64-bit configurations. And for 'make
randconfig' on a machine without PAE to generate a kernel which uses
(and thus requires) PAE. And for 'make randconfig' on a machine without
3DNow to generate a kernel that uses (and thus requires) 3DNow.

That's exactly what you get on every other architecture, isn't it?
Random means random. It's only x86 that never quite finished the merge
of arch/i386 and arch/x86_64 into one, and was inconsistent.

>  In the past, "make randconfig" would always generate a kernel that
> _should_ boot on that machine unless there was an underlying 
> bug that should be fixed.

No, that was not the case. I've given some examples above — and good
luck mounting your root file system if you have neither the block device
nor the corresponding file system support. Not to mention CGROUPS
support or whatever else your userland requires in order to boot.

If you want it bootable, there *are* ways for you to override just
enough of the config options to ensure that — as I've repeatedly said.
But doing *just* CONFIG_64BIT is far from sufficient.

> > > > Please could you provide the .config file?
> > 
> > > Attached.
> > 
> > Didn't seem to be.
> > 
> 
> Now it is, sorry.

Thanks. I'll look into this. I presume it was *always* failing, but
nobody happened to come across it because our test coverage of x86
configs without CONFIG_64BIT wasn't particularly good?

> > I just don't buy this "OMG you made randconfig actually random" crap.
> > It's a stupid thing to complain about. Making some effort to pick
> > i386_defconfig or x86_64_defconfig according to the build host, we can
> > tolerate. But randconfig is *supposed* to be random. Get over it.
> > 
> 
> I'm stupid for saying that you've changed the behavior of "make 
> randconfig" with no ARCH= workaround so that it may result in an 
> unbootable kernel on i386? 

Nothing changed significantly there. You could *always* get an
unbootable kernel that way. The *odds* may have changed, but that's all.

The mechanism for you to *ensure* that you get a bootable result, as I
keep reminding you, still works fine.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2012-12-26 22:00           ` David Rientjes
  2012-12-26 22:19             ` David Woodhouse
@ 2012-12-26 22:30             ` Jesper Juhl
  2012-12-26 23:07             ` David Woodhouse
  2012-12-26 23:13             ` H. Peter Anvin
  3 siblings, 0 replies; 65+ messages in thread
From: Jesper Juhl @ 2012-12-26 22:30 UTC (permalink / raw)
  To: David Rientjes
  Cc: David Woodhouse, Ingo Molnar, H. Peter Anvin, tglx,
	H. Peter Anvin, linux-kernel, linux-tip-commits

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2697 bytes --]

On Wed, 26 Dec 2012, David Rientjes wrote:

> On Wed, 26 Dec 2012, David Woodhouse wrote:
> 
> > > I'm sure it's a 32-bit issue, nothing has changed recently in auto-latest 
> > > related to these subsystems and I'm sure it's just because my randconfig 
> > > builds were exposed to this combination solely because of this patch.
> > 
> > Hm, that's an unexpected benefit of this patch. I didn't think it would
> > noticeably improve 'make randconfig' coverage of configs without
> > CONFIG_64BIT, because I thought enough people were doing such tests
> > already. But evidently I was wrong.
> > 
> 
> I do quite a bit of automated config and boot tests to try out 
> combinations that others may not have tested when developing their code; 
> staging branches such as in tip are interesting to try because they 
> haven't yet reached Linus and it's helpful to catch breakages before it 
> reaches mainline.
> 
> > We introduced 'make randconfig' as a tool to generate meaningless
> > configs just to test various permutations — to ensure that we got our
> > dependencies right both in Kconfig and the code itself. It was
> > artificially limiting its test coverage and thus we were failing to
> > discover real bugs. Now I've fixed that problem, and 'make randconfig'
> > is actually random and is thus doing its job even better than before.
> > Yay!
> > 
> 
> Umm, you're saying that is legitimate for "make randconfig" done on a 
> 32-bit machine to generate 64-bit configurations?  The resulting kernel 
> cannot be booted.  In the past, "make randconfig" would always generate a 
> kernel that _should_ boot on that machine unless there was an underlying 
> bug that should be fixed.
> 
...

Why would you assume a bootable kernel from 'randconfig'? I don't and 
never have. If we stick to X86, then you may get a kernel config without 
x387/emulator support - try to boot boot that on a 486sx. You may also get 
a config that does not contain the filesystem(s) you use, or without the 
driver for your main HD. You may also be out of luck with graphics 
drivers or support for your mouse/keyboard combo. etc etc.

In my view, randconfig was never about building bootable kernels, but all 
about building possible kernel config combinations - that may or may not 
boot on any given system.  The point was only to test that some 
combination of options did in fact build (if it also boots then all the 
better, but that was never part of the goal; as I saw it).

I may be wrong, but that was/is my expectations for 'randconfig'.

-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2012-12-26 22:00           ` David Rientjes
  2012-12-26 22:19             ` David Woodhouse
  2012-12-26 22:30             ` Jesper Juhl
@ 2012-12-26 23:07             ` David Woodhouse
  2012-12-26 23:13             ` H. Peter Anvin
  3 siblings, 0 replies; 65+ messages in thread
From: David Woodhouse @ 2012-12-26 23:07 UTC (permalink / raw)
  To: David Rientjes
  Cc: Ingo Molnar, H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel,
	linux-tip-commits

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

On Wed, 2012-12-26 at 14:00 -0800, David Rientjes wrote:
> I do quite a bit of automated config and boot tests to try out 
> combinations that others may not have tested when developing their
> code; staging branches such as in tip are interesting to try because
> they haven't yet reached Linus and it's helpful to catch breakages
> before it reaches mainline.

Indeed. It seems quite broken at the moment.

Your config builds fine in the tip of Linus' current tree (with
ARCH=i386 or ARCH=x86 of course). But breaks on tip.git as you describe.
The first commit I hit when attempting to bisect (2bd24259f78) is
*differently* buggered:

  CC      arch/x86/kernel/ptrace.o
arch/x86/kernel/ptrace.c:1350:17: error: conflicting types for ‘syscall_trace_enter’
In file included from /ssd/git/tip/arch/x86/include/asm/vm86.h:130:0,
                 from /ssd/git/tip/arch/x86/include/asm/processor.h:10,
                 from /ssd/git/tip/arch/x86/include/asm/thread_info.h:22,
                 from include/linux/thread_info.h:56,
                 from include/linux/preempt.h:9,
                 from include/linux/spinlock.h:50,
                 from include/linux/seqlock.h:29,
                 from include/linux/time.h:8,
                 from include/linux/timex.h:56,
                 from include/linux/sched.h:56,
                 from arch/x86/kernel/ptrace.c:8:
/ssd/git/tip/arch/x86/include/asm/ptrace.h:146:13: note: previous declaration of ‘syscall_trace_enter’ was here

I'll persist, but the build failure you describe looks like it's a
simple failure of the 32-bit build in tip.git, which 'randconfig' was
*designed* to catch... but of course it wasn't doing its job very well
until I fixed it. It's entirely inappropriate to *blame* it on my patch.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2012-12-26 22:00           ` David Rientjes
                               ` (2 preceding siblings ...)
  2012-12-26 23:07             ` David Woodhouse
@ 2012-12-26 23:13             ` H. Peter Anvin
  3 siblings, 0 replies; 65+ messages in thread
From: H. Peter Anvin @ 2012-12-26 23:13 UTC (permalink / raw)
  To: David Rientjes
  Cc: David Woodhouse, Ingo Molnar, tglx, H. Peter Anvin, linux-kernel,
	linux-tip-commits

On 12/26/2012 02:00 PM, David Rientjes wrote:
 >
> In the past, "make randconfig" would always generate a
> kernel that _should_ boot on that machine unless there was an underlying
> bug that should be fixed.
 >

Not even remotely true.  There are tons of options which may not be set 
that your machine needs, or you might set options that exclude support 
for your CPU, for example.

Seriously, this is a bad joke.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip] config: Add 'make kvmconfig'
  2012-12-26  6:32   ` David Rientjes
  2012-12-26  8:43     ` David Woodhouse
@ 2012-12-26 23:32     ` David Woodhouse
  2012-12-27  1:08       ` Randy Dunlap
  1 sibling, 1 reply; 65+ messages in thread
From: David Woodhouse @ 2012-12-26 23:32 UTC (permalink / raw)
  To: David Rientjes, Sasha Levin, Michal Marek
  Cc: Ingo Molnar, H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel,
	linux-tip-commits

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On Tue, 2012-12-25 at 22:32 -0800, David Rientjes wrote:
> 
> This creates quite a few build failures on auto-latest:
> 
> arch/x86/built-in.o: In function `hpet_setup_msi_irq':
> hpet.c:(.text+0x34638): undefined reference to `arch_setup_hpet_msi'
> hpet.c:(.text+0x34651): undefined reference to `destroy_irq'
> arch/x86/built-in.o: In function `hpet_msi_capability_lookup':
> hpet.c:(.text+0x347ff): undefined reference to `create_irq_nr'
> arch/x86/built-in.o:(.data+0xd1c): undefined reference to `native_setup_msi_irqs'
> arch/x86/built-in.o:(.data+0xd20): undefined reference to `native_teardown_msi_irq'

This one is actually caused by commit 3b08ed026 (config: Add 'make
kvmconfig'), which selects PCI_MSI even on a 32-bit config where it's
invalid to do so.

Ew, that commit seems like a *completely* wrong-headed idea. That abuse
of 'select' is just begging for this kind of breakage. We have other
ways to merge configs and turn certain options on, without doing it this
way.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip] config: Add 'make kvmconfig'
  2012-12-26 23:32     ` [tip] config: Add 'make kvmconfig' David Woodhouse
@ 2012-12-27  1:08       ` Randy Dunlap
  2013-02-04 18:20         ` [patch] config: fix make kvmconfig David Rientjes
  0 siblings, 1 reply; 65+ messages in thread
From: Randy Dunlap @ 2012-12-27  1:08 UTC (permalink / raw)
  To: David Woodhouse
  Cc: David Rientjes, Sasha Levin, Michal Marek, Ingo Molnar,
	H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel,
	linux-tip-commits

On 12/26/12 15:32, David Woodhouse wrote:
> On Tue, 2012-12-25 at 22:32 -0800, David Rientjes wrote:
>>
>> This creates quite a few build failures on auto-latest:
>>
>> arch/x86/built-in.o: In function `hpet_setup_msi_irq':
>> hpet.c:(.text+0x34638): undefined reference to `arch_setup_hpet_msi'
>> hpet.c:(.text+0x34651): undefined reference to `destroy_irq'
>> arch/x86/built-in.o: In function `hpet_msi_capability_lookup':
>> hpet.c:(.text+0x347ff): undefined reference to `create_irq_nr'
>> arch/x86/built-in.o:(.data+0xd1c): undefined reference to `native_setup_msi_irqs'
>> arch/x86/built-in.o:(.data+0xd20): undefined reference to `native_teardown_msi_irq'

I reported these build errors in linux-next on Nov. 7, 2011 !!!

> This one is actually caused by commit 3b08ed026 (config: Add 'make
> kvmconfig'), which selects PCI_MSI even on a 32-bit config where it's
> invalid to do so.
> 
> Ew, that commit seems like a *completely* wrong-headed idea. That abuse
> of 'select' is just begging for this kind of breakage. We have other
> ways to merge configs and turn certain options on, without doing it this
> way.

but I didn't diagnose the problem.  Thanks for that.

Yes, 'make kvmconfig' takes liberties and shortcuts.  :(

-- 
~Randy

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2012-12-26 22:19             ` David Woodhouse
@ 2012-12-27  1:52               ` David Rientjes
  2012-12-27  8:01                 ` David Woodhouse
  0 siblings, 1 reply; 65+ messages in thread
From: David Rientjes @ 2012-12-27  1:52 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Ingo Molnar, H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel,
	linux-tip-commits

On Wed, 26 Dec 2012, David Woodhouse wrote:

> Thanks. I'll look into this. I presume it was *always* failing, but
> nobody happened to come across it because our test coverage of x86
> configs without CONFIG_64BIT wasn't particularly good?
> 

Purely for selfish reasons, 32-bit isn't interesting for me.  I'm sure 
they existed before, as you said, but only got exposed to be because "make 
randconfig" now allows such configurations.  I've added ARCH=x86_64 to my 
scripts.

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2012-12-27  1:52               ` David Rientjes
@ 2012-12-27  8:01                 ` David Woodhouse
  0 siblings, 0 replies; 65+ messages in thread
From: David Woodhouse @ 2012-12-27  8:01 UTC (permalink / raw)
  To: David Rientjes
  Cc: Ingo Molnar, H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel,
	linux-tip-commits

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

On Wed, 2012-12-26 at 17:52 -0800, David Rientjes wrote:
> On Wed, 26 Dec 2012, David Woodhouse wrote:
> 
> > Thanks. I'll look into this. I presume it was *always* failing, but
> > nobody happened to come across it because our test coverage of x86
> > configs without CONFIG_64BIT wasn't particularly good?
> > 
> 
> Purely for selfish reasons, 32-bit isn't interesting for me.  I'm sure 
> they existed before, as you said, but only got exposed to be because "make 
> randconfig" now allows such configurations.  I've added ARCH=x86_64 to my 
> scripts.

I recommend using an all.config file instead, which will allow you to
set not only the value for CONFIG_64BIT but also anything *else* you
want to exclude. Especially if you want things to actually be bootable,
that will be necessary.

The legacy i386/x86_64 values for $ARCH from before the merge are
basically no longer needed. The *only* thing they do is override the
CONFIG_64BIT setting, IIRC. So they ought to be able to go away in time,
and starting to use them in scripts now is probably not the best idea.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2012-12-21  2:07 ` [tip:x86/build] x86: Default to ARCH= x86 " tip-bot for David Woodhouse
  2012-12-26  6:32   ` David Rientjes
@ 2013-01-12 17:06   ` Borislav Petkov
  2013-01-12 17:40     ` H. Peter Anvin
  1 sibling, 1 reply; 65+ messages in thread
From: Borislav Petkov @ 2013-01-12 17:06 UTC (permalink / raw)
  To: David Woodhouse
  Cc: mingo, hpa, linux-kernel, tglx, hpa, David.Woodhouse, linux-tip-commits

On Thu, Dec 20, 2012 at 06:07:46PM -0800, tip-bot for David Woodhouse wrote:
> Commit-ID:  ffee0de411fd4f74f3b788892eeb075abbf26c52
> Gitweb:     http://git.kernel.org/tip/ffee0de411fd4f74f3b788892eeb075abbf26c52
> Author:     David Woodhouse <dwmw2@infradead.org>
> AuthorDate: Thu, 20 Dec 2012 21:51:55 +0000
> Committer:  H. Peter Anvin <hpa@linux.intel.com>
> CommitDate: Thu, 20 Dec 2012 14:37:18 -0800
> 
> x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT
> 
> It is easy to waste a bunch of time when one takes a 32-bit .config
> from a test machine and try to build it on a faster 64-bit system, and
> its existing setting of CONFIG_64BIT=n gets *changed* to match the
> build host.  Similarly, if one has an existing build tree it is easy
> to trash an entire build tree that way.
> 
> This is because the default setting for $ARCH when discovered from
> 'uname' is one of the legacy pre-x86-merge values (i386 or x86_64),
> which effectively force the setting of CONFIG_64BIT to match. We should
> default to ARCH=x86 instead, finally completing the merge that we
> started so long ago.

Ok, I don't know whether this was on purpose or not but setting ARCH=x86
has the side effect of putting the config 64BIT prompt into the toplevel
menuconfig:

	[*] 64-bit kernel
	    General setup  --->
	[*] Enable loadable module support  --->
	[*] Enable the block layer  --->
	    Processor type and features  --->

Now, IMHO, maybe the more fitting place for this should be "Processor
type and features" where all the arch-specific stuff goes but looking at
arch/x86/Kconfig, it would need some restructuring due to dependencies.

So how about we simply hide it by still preserving the functionality:

--
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 50b1b1bf442b..e8d7e9250853 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1,6 +1,7 @@
 # Select 32 or 64 bit
 config 64BIT
-	bool "64-bit kernel" if ARCH = "x86"
+	bool
+	default y if ARCH = "x86"
 	default ARCH != "i386"
 	---help---
 	  Say yes to build a 64-bit kernel - formerly known as x86_64

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

^ permalink raw reply related	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2013-01-12 17:06   ` [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT Borislav Petkov
@ 2013-01-12 17:40     ` H. Peter Anvin
  2013-01-12 18:08       ` Borislav Petkov
  0 siblings, 1 reply; 65+ messages in thread
From: H. Peter Anvin @ 2013-01-12 17:40 UTC (permalink / raw)
  To: Borislav Petkov, David Woodhouse, mingo, linux-kernel, tglx, hpa,
	David.Woodhouse, linux-tip-commits

On 01/12/2013 09:06 AM, Borislav Petkov wrote:
> 
> Ok, I don't know whether this was on purpose or not but setting ARCH=x86
> has the side effect of putting the config 64BIT prompt into the toplevel
> menuconfig:
> 
> 	[*] 64-bit kernel
> 	    General setup  --->
> 	[*] Enable loadable module support  --->
> 	[*] Enable the block layer  --->
> 	    Processor type and features  --->
> 
> Now, IMHO, maybe the more fitting place for this should be "Processor
> type and features" where all the arch-specific stuff goes but looking at
> arch/x86/Kconfig, it would need some restructuring due to dependencies.
> 
> So how about we simply hide it by still preserving the functionality:
> 

Hiding it because it happens to be in a slightly illogical place seems
completely backwards.

	-hpa



^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2013-01-12 17:40     ` H. Peter Anvin
@ 2013-01-12 18:08       ` Borislav Petkov
  2013-01-12 18:10         ` H. Peter Anvin
  0 siblings, 1 reply; 65+ messages in thread
From: Borislav Petkov @ 2013-01-12 18:08 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: David Woodhouse, mingo, linux-kernel, tglx, hpa, David.Woodhouse,
	linux-tip-commits

On Sat, Jan 12, 2013 at 09:40:20AM -0800, H. Peter Anvin wrote:
> Hiding it because it happens to be in a slightly illogical place seems
> completely backwards.

Sure, that's the lazy dude solution™ :-)

I could try to restructure arch/x86/Kconfig but is it worth the trouble
to fix the "slightly illogical" placing...

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
  2013-01-12 18:08       ` Borislav Petkov
@ 2013-01-12 18:10         ` H. Peter Anvin
  0 siblings, 0 replies; 65+ messages in thread
From: H. Peter Anvin @ 2013-01-12 18:10 UTC (permalink / raw)
  To: Borislav Petkov, David Woodhouse, mingo, linux-kernel, tglx, hpa,
	David.Woodhouse, linux-tip-commits

On 01/12/2013 10:08 AM, Borislav Petkov wrote:
> On Sat, Jan 12, 2013 at 09:40:20AM -0800, H. Peter Anvin wrote:
>> Hiding it because it happens to be in a slightly illogical place seems
>> completely backwards.
>
> Sure, that's the lazy dude solution™ :-)
>
> I could try to restructure arch/x86/Kconfig but is it worth the trouble
> to fix the "slightly illogical" placing...
>

Well, it's more than that.  It is actually removing functionality 
because it is "illogically placed"... that cure is worse than the disease.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


^ permalink raw reply	[flat|nested] 65+ messages in thread

* [patch] config: fix make kvmconfig
  2012-12-27  1:08       ` Randy Dunlap
@ 2013-02-04 18:20         ` David Rientjes
  2013-02-04 18:44           ` Ingo Molnar
  0 siblings, 1 reply; 65+ messages in thread
From: David Rientjes @ 2013-02-04 18:20 UTC (permalink / raw)
  To: Pekka Enberg, Sasha Levin
  Cc: Randy Dunlap, David Woodhouse, Michal Marek, Ingo Molnar,
	H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel

make kvmconfig selects CONFIG_SERIAL_8250 without selecting its 
dependencies causing some configs to fail:

drivers/tty/serial/8250/8250.c:57:32: error: 'CONFIG_SERIAL_8250_RUNTIME_UARTS' undeclared here (not in a function)
drivers/tty/serial/8250/8250.c:2712:47: error: 'CONFIG_SERIAL_8250_NR_UARTS' undeclared here (not in a function)
drivers/tty/serial/8250/8250.c: In function 'serial8250_console_write':
drivers/tty/serial/8250/8250.c:2843:10: error: 'struct uart_port' has no member named 'sysrq'
drivers/tty/serial/8250/8250.c: In function 'early_serial_setup':
drivers/tty/serial/8250/8250.c:2971:20: error: negative width in bit-field '<anonymous>'
drivers/tty/serial/8250/8250.c: At top level:
drivers/tty/serial/8250/8250.c:2712:30: warning: 'serial8250_ports' defined but not used [-Wunused-variable]

Fix this by selecting CONFIG_TTY as well, which CONFIG_SERIAL_8250 
requires.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 Ok, so this patch has been sitting in linux-next for well over a year and
 has had to be fixed several times with follow up commits similar to this.
 Linus hasn't pulled kvmtool, so I'm wondering why we need to keep this
 around in the first place?

 arch/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 6979498..f9459b3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -606,6 +606,7 @@ config KVMTOOL_TEST_ENABLE
 	select NETWORK_FILESYSTEMS
 	select INET
 	select EXPERIMENTAL
+	select TTY
 	select SERIAL_8250
 	select SERIAL_8250_CONSOLE
 	select IP_PNP

^ permalink raw reply related	[flat|nested] 65+ messages in thread

* Re: [patch] config: fix make kvmconfig
  2013-02-04 18:20         ` [patch] config: fix make kvmconfig David Rientjes
@ 2013-02-04 18:44           ` Ingo Molnar
  2013-02-04 18:57             ` David Rientjes
  0 siblings, 1 reply; 65+ messages in thread
From: Ingo Molnar @ 2013-02-04 18:44 UTC (permalink / raw)
  To: David Rientjes
  Cc: Pekka Enberg, Sasha Levin, Randy Dunlap, David Woodhouse,
	Michal Marek, H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel


* David Rientjes <rientjes@google.com> wrote:

>  arch/x86/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 6979498..f9459b3 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -606,6 +606,7 @@ config KVMTOOL_TEST_ENABLE
>  	select NETWORK_FILESYSTEMS
>  	select INET
>  	select EXPERIMENTAL
> +	select TTY
>  	select SERIAL_8250
>  	select SERIAL_8250_CONSOLE
>  	select IP_PNP

There's no 'config TTY' in the kernel AFAICS.

Did you mean:

	select SERIAL_CORE
	select SERIAL_CORE_CONSOLE

?

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [patch] config: fix make kvmconfig
  2013-02-04 18:44           ` Ingo Molnar
@ 2013-02-04 18:57             ` David Rientjes
  2013-02-04 19:11               ` Ingo Molnar
  2013-02-04 19:14               ` Greg Kroah-Hartman
  0 siblings, 2 replies; 65+ messages in thread
From: David Rientjes @ 2013-02-04 18:57 UTC (permalink / raw)
  To: Ingo Molnar, Greg Kroah-Hartman
  Cc: Pekka Enberg, Sasha Levin, Randy Dunlap, David Woodhouse,
	Michal Marek, H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel

On Mon, 4 Feb 2013, Ingo Molnar wrote:

> >  arch/x86/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 6979498..f9459b3 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -606,6 +606,7 @@ config KVMTOOL_TEST_ENABLE
> >  	select NETWORK_FILESYSTEMS
> >  	select INET
> >  	select EXPERIMENTAL
> > +	select TTY
> >  	select SERIAL_8250
> >  	select SERIAL_8250_CONSOLE
> >  	select IP_PNP
> 
> There's no 'config TTY' in the kernel AFAICS.
> 

It's added in linux-next by 4f73bc4dd3e8 ("tty: Added a CONFIG_TTY option 
to allow removal of TTY").

Adding Greg to the cc to figure out which tree this should be merged 
through.  Greg, please find the patch inline.

The better alternative would be to remove KVMTOOL_TEST_ENABLE entirely 
since it has been sitting in linux-next for over a year, Linus has said he 
won't pull it, and it consistently needs updates both inside and outside 
of Pekka's tree.

-----o<-----

config: fix make kvmconfig

make kvmconfig selects CONFIG_SERIAL_8250 without selecting its 
dependencies causing some configs to fail:

drivers/tty/serial/8250/8250.c:57:32: error: 'CONFIG_SERIAL_8250_RUNTIME_UARTS' undeclared here (not in a function)
drivers/tty/serial/8250/8250.c:2712:47: error: 'CONFIG_SERIAL_8250_NR_UARTS' undeclared here (not in a function)
drivers/tty/serial/8250/8250.c: In function 'serial8250_console_write':
drivers/tty/serial/8250/8250.c:2843:10: error: 'struct uart_port' has no member named 'sysrq'
drivers/tty/serial/8250/8250.c: In function 'early_serial_setup':
drivers/tty/serial/8250/8250.c:2971:20: error: negative width in bit-field '<anonymous>'
drivers/tty/serial/8250/8250.c: At top level:
drivers/tty/serial/8250/8250.c:2712:30: warning: 'serial8250_ports' defined but not used [-Wunused-variable]

Fix this by selecting CONFIG_TTY as well, which CONFIG_SERIAL_8250 
requires.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 arch/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 6979498..f9459b3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -606,6 +606,7 @@ config KVMTOOL_TEST_ENABLE
 	select NETWORK_FILESYSTEMS
 	select INET
 	select EXPERIMENTAL
+	select TTY
 	select SERIAL_8250
 	select SERIAL_8250_CONSOLE
 	select IP_PNP

^ permalink raw reply related	[flat|nested] 65+ messages in thread

* Re: [patch] config: fix make kvmconfig
  2013-02-04 18:57             ` David Rientjes
@ 2013-02-04 19:11               ` Ingo Molnar
  2013-02-04 19:14               ` Greg Kroah-Hartman
  1 sibling, 0 replies; 65+ messages in thread
From: Ingo Molnar @ 2013-02-04 19:11 UTC (permalink / raw)
  To: David Rientjes
  Cc: Greg Kroah-Hartman, Pekka Enberg, Sasha Levin, Randy Dunlap,
	David Woodhouse, Michal Marek, H. Peter Anvin, tglx,
	H. Peter Anvin, linux-kernel


* David Rientjes <rientjes@google.com> wrote:

> On Mon, 4 Feb 2013, Ingo Molnar wrote:
> 
> > >  arch/x86/Kconfig | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > index 6979498..f9459b3 100644
> > > --- a/arch/x86/Kconfig
> > > +++ b/arch/x86/Kconfig
> > > @@ -606,6 +606,7 @@ config KVMTOOL_TEST_ENABLE
> > >  	select NETWORK_FILESYSTEMS
> > >  	select INET
> > >  	select EXPERIMENTAL
> > > +	select TTY
> > >  	select SERIAL_8250
> > >  	select SERIAL_8250_CONSOLE
> > >  	select IP_PNP
> > 
> > There's no 'config TTY' in the kernel AFAICS.
> > 
> 
> It's added in linux-next by 4f73bc4dd3e8 ("tty: Added a 
> CONFIG_TTY option to allow removal of TTY").
> 
> Adding Greg to the cc to figure out which tree this should be 
> merged through.  Greg, please find the patch inline.
> 
> The better alternative would be to remove KVMTOOL_TEST_ENABLE 
> entirely since it has been sitting in linux-next for over a 
> year, Linus has said he won't pull it, and it consistently 
> needs updates both inside and outside of Pekka's tree.

Looks like this is a merge artifact then. I'll fix it once 
Greg's changes hit upstream.

'make kvmconfig' generally works fine in my tree, and I'm using 
it for testing on an almost daily basis.

It's never run by default and you have to actively use it, so it 
cannot regress any existing code AFAICS.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [patch] config: fix make kvmconfig
  2013-02-04 19:14               ` Greg Kroah-Hartman
@ 2013-02-04 19:13                 ` Ingo Molnar
  2013-02-06 18:25                   ` Pekka Enberg
  0 siblings, 1 reply; 65+ messages in thread
From: Ingo Molnar @ 2013-02-04 19:13 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: David Rientjes, Pekka Enberg, Sasha Levin, Randy Dunlap,
	David Woodhouse, Michal Marek, H. Peter Anvin, tglx,
	H. Peter Anvin, linux-kernel


* Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Mon, Feb 04, 2013 at 10:57:35AM -0800, David Rientjes wrote:
> > On Mon, 4 Feb 2013, Ingo Molnar wrote:
> > 
> > > >  arch/x86/Kconfig | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > > index 6979498..f9459b3 100644
> > > > --- a/arch/x86/Kconfig
> > > > +++ b/arch/x86/Kconfig
> > > > @@ -606,6 +606,7 @@ config KVMTOOL_TEST_ENABLE
> > > >  	select NETWORK_FILESYSTEMS
> > > >  	select INET
> > > >  	select EXPERIMENTAL
> > > > +	select TTY
> > > >  	select SERIAL_8250
> > > >  	select SERIAL_8250_CONSOLE
> > > >  	select IP_PNP
> > > 
> > > There's no 'config TTY' in the kernel AFAICS.
> > > 
> > 
> > It's added in linux-next by 4f73bc4dd3e8 ("tty: Added a CONFIG_TTY option 
> > to allow removal of TTY").
> > 
> > Adding Greg to the cc to figure out which tree this should be merged 
> > through.  Greg, please find the patch inline.
> 
> Ideally it would go through my tree, but it can't because 
> KVMTOOL_TEST_ENABLE isn't in my tree :(
> 
> I suggest just adding it to whatever tree this change is in, 
> it doesn't "hurt" to enable a config option that isn't in the 
> tree at the moment, right?  Or will Kconfig complain about it?

Yeah, that's a good idea - I think Pekka can apply that change 
just fine to help anyone doing merges - I don't think kconfig 
treats it as a fatal error.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [patch] config: fix make kvmconfig
  2013-02-04 18:57             ` David Rientjes
  2013-02-04 19:11               ` Ingo Molnar
@ 2013-02-04 19:14               ` Greg Kroah-Hartman
  2013-02-04 19:13                 ` Ingo Molnar
  1 sibling, 1 reply; 65+ messages in thread
From: Greg Kroah-Hartman @ 2013-02-04 19:14 UTC (permalink / raw)
  To: David Rientjes
  Cc: Ingo Molnar, Pekka Enberg, Sasha Levin, Randy Dunlap,
	David Woodhouse, Michal Marek, H. Peter Anvin, tglx,
	H. Peter Anvin, linux-kernel

On Mon, Feb 04, 2013 at 10:57:35AM -0800, David Rientjes wrote:
> On Mon, 4 Feb 2013, Ingo Molnar wrote:
> 
> > >  arch/x86/Kconfig | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > index 6979498..f9459b3 100644
> > > --- a/arch/x86/Kconfig
> > > +++ b/arch/x86/Kconfig
> > > @@ -606,6 +606,7 @@ config KVMTOOL_TEST_ENABLE
> > >  	select NETWORK_FILESYSTEMS
> > >  	select INET
> > >  	select EXPERIMENTAL
> > > +	select TTY
> > >  	select SERIAL_8250
> > >  	select SERIAL_8250_CONSOLE
> > >  	select IP_PNP
> > 
> > There's no 'config TTY' in the kernel AFAICS.
> > 
> 
> It's added in linux-next by 4f73bc4dd3e8 ("tty: Added a CONFIG_TTY option 
> to allow removal of TTY").
> 
> Adding Greg to the cc to figure out which tree this should be merged 
> through.  Greg, please find the patch inline.

Ideally it would go through my tree, but it can't because
KVMTOOL_TEST_ENABLE isn't in my tree :(

I suggest just adding it to whatever tree this change is in, it doesn't
"hurt" to enable a config option that isn't in the tree at the moment,
right?  Or will Kconfig complain about it?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [patch] config: fix make kvmconfig
  2013-02-04 19:13                 ` Ingo Molnar
@ 2013-02-06 18:25                   ` Pekka Enberg
  2013-02-06 20:12                     ` David Rientjes
  0 siblings, 1 reply; 65+ messages in thread
From: Pekka Enberg @ 2013-02-06 18:25 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Greg Kroah-Hartman, David Rientjes, Sasha Levin, Randy Dunlap,
	David Woodhouse, Michal Marek, H. Peter Anvin, tglx,
	H. Peter Anvin, linux-kernel

On Mon, Feb 4, 2013 at 9:13 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
>> On Mon, Feb 04, 2013 at 10:57:35AM -0800, David Rientjes wrote:
>> > On Mon, 4 Feb 2013, Ingo Molnar wrote:
>> >
>> > > >  arch/x86/Kconfig | 1 +
>> > > >  1 file changed, 1 insertion(+)
>> > > >
>> > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> > > > index 6979498..f9459b3 100644
>> > > > --- a/arch/x86/Kconfig
>> > > > +++ b/arch/x86/Kconfig
>> > > > @@ -606,6 +606,7 @@ config KVMTOOL_TEST_ENABLE
>> > > >         select NETWORK_FILESYSTEMS
>> > > >         select INET
>> > > >         select EXPERIMENTAL
>> > > > +       select TTY
>> > > >         select SERIAL_8250
>> > > >         select SERIAL_8250_CONSOLE
>> > > >         select IP_PNP
>> > >
>> > > There's no 'config TTY' in the kernel AFAICS.
>> > >
>> >
>> > It's added in linux-next by 4f73bc4dd3e8 ("tty: Added a CONFIG_TTY option
>> > to allow removal of TTY").
>> >
>> > Adding Greg to the cc to figure out which tree this should be merged
>> > through.  Greg, please find the patch inline.
>>
>> Ideally it would go through my tree, but it can't because
>> KVMTOOL_TEST_ENABLE isn't in my tree :(
>>
>> I suggest just adding it to whatever tree this change is in,
>> it doesn't "hurt" to enable a config option that isn't in the
>> tree at the moment, right?  Or will Kconfig complain about it?
>
> Yeah, that's a good idea - I think Pekka can apply that change
> just fine to help anyone doing merges - I don't think kconfig
> treats it as a fatal error.

Applied, thanks guys!

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [patch] config: fix make kvmconfig
  2013-02-06 18:25                   ` Pekka Enberg
@ 2013-02-06 20:12                     ` David Rientjes
  2013-02-06 20:45                       ` Pekka Enberg
  2013-02-06 21:02                       ` kvmtool tree (Was: Re: [patch] config: fix make kvmconfig) Stephen Rothwell
  0 siblings, 2 replies; 65+ messages in thread
From: David Rientjes @ 2013-02-06 20:12 UTC (permalink / raw)
  To: Pekka Enberg, Stephen Rothwell
  Cc: Linus Torvalds, Ingo Molnar, Greg Kroah-Hartman, Sasha Levin,
	Randy Dunlap, David Woodhouse, Michal Marek, H. Peter Anvin,
	tglx, H. Peter Anvin, linux-kernel

On Wed, 6 Feb 2013, Pekka Enberg wrote:

> > Yeah, that's a good idea - I think Pekka can apply that change
> > just fine to help anyone doing merges - I don't think kconfig
> > treats it as a fatal error.
> 
> Applied, thanks guys!
> 

Adding Stephen to the cc.

What's the endgame for kvmtool/next?  The patch that this fixes has been 
sitting in linux-next for over 15 months and hasn't been pulled by Linus, 
yet some find it to be quite useful.

Is it a permanent addition to linux-next, is there a route to mainline, 
or something else?

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [patch] config: fix make kvmconfig
  2013-02-06 20:12                     ` David Rientjes
@ 2013-02-06 20:45                       ` Pekka Enberg
  2013-02-06 21:02                       ` kvmtool tree (Was: Re: [patch] config: fix make kvmconfig) Stephen Rothwell
  1 sibling, 0 replies; 65+ messages in thread
From: Pekka Enberg @ 2013-02-06 20:45 UTC (permalink / raw)
  To: David Rientjes
  Cc: Stephen Rothwell, Linus Torvalds, Ingo Molnar,
	Greg Kroah-Hartman, Sasha Levin, Randy Dunlap, David Woodhouse,
	Michal Marek, H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel

On Wed, Feb 6, 2013 at 10:12 PM, David Rientjes <rientjes@google.com> wrote:
> What's the endgame for kvmtool/next?  The patch that this fixes has been
> sitting in linux-next for over 15 months and hasn't been pulled by Linus,
> yet some find it to be quite useful.
>
> Is it a permanent addition to linux-next, is there a route to mainline,
> or something else?

It is actively developed and has recently gained support for ARM, for
example. Ingo keeps pulling it to the -tip tree so tools/kvm also
appears on linux-next through that. Linus doesn't think it's worth
pulling and the KVM maintainers are uninterested.

So I guess we've deadlocked the Linux kernel development process?

^ permalink raw reply	[flat|nested] 65+ messages in thread

* kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-06 20:12                     ` David Rientjes
  2013-02-06 20:45                       ` Pekka Enberg
@ 2013-02-06 21:02                       ` Stephen Rothwell
  2013-02-06 21:46                         ` Ingo Molnar
  1 sibling, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2013-02-06 21:02 UTC (permalink / raw)
  To: David Rientjes
  Cc: Pekka Enberg, Linus Torvalds, Ingo Molnar, Greg Kroah-Hartman,
	Sasha Levin, Randy Dunlap, David Woodhouse, Michal Marek,
	H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

Hi David,

On Wed, 6 Feb 2013 12:12:57 -0800 (PST) David Rientjes <rientjes@google.com> wrote:
>
> On Wed, 6 Feb 2013, Pekka Enberg wrote:
> 
> > > Yeah, that's a good idea - I think Pekka can apply that change
> > > just fine to help anyone doing merges - I don't think kconfig
> > > treats it as a fatal error.
> > 
> > Applied, thanks guys!
> 
> Adding Stephen to the cc.
> 
> What's the endgame for kvmtool/next?  The patch that this fixes has been 
> sitting in linux-next for over 15 months and hasn't been pulled by Linus, 
> yet some find it to be quite useful.
> 
> Is it a permanent addition to linux-next, is there a route to mainline, 
> or something else?

Linus has said that he will not take the kvmtool tree in its current
form, but would prefer that it be a separate project, so I should really
drop it from linux-next (and ask the tip guys to remove it from their
auto-latest branch).

I have actually been meaning to get back to this, so, today I will drop
the kvmtool tree and, Ingo, if you could (at your convenience i.e. when
you are next rebasing it) remove it from tip/auto-latest, thanks.

This does not, of course, rule out it being reinstated if Linus can be
convinced.  Nor does it make a judgement on the project itself, it is
just because linux-next is meant to represent what is to be merged into
Linus' tree in the next merge window.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-06 21:02                       ` kvmtool tree (Was: Re: [patch] config: fix make kvmconfig) Stephen Rothwell
@ 2013-02-06 21:46                         ` Ingo Molnar
  2013-02-06 21:55                           ` H. Peter Anvin
  2013-02-07 21:40                           ` Stephen Rothwell
  0 siblings, 2 replies; 65+ messages in thread
From: Ingo Molnar @ 2013-02-06 21:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Rientjes, Pekka Enberg, Linus Torvalds, Greg Kroah-Hartman,
	Sasha Levin, Randy Dunlap, David Woodhouse, Michal Marek,
	H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi David,
> 
> On Wed, 6 Feb 2013 12:12:57 -0800 (PST) David Rientjes <rientjes@google.com> wrote:
> >
> > On Wed, 6 Feb 2013, Pekka Enberg wrote:
> > 
> > > > Yeah, that's a good idea - I think Pekka can apply that change
> > > > just fine to help anyone doing merges - I don't think kconfig
> > > > treats it as a fatal error.
> > > 
> > > Applied, thanks guys!
> > 
> > Adding Stephen to the cc.
> > 
> > What's the endgame for kvmtool/next?  The patch that this fixes has been 
> > sitting in linux-next for over 15 months and hasn't been pulled by Linus, 
> > yet some find it to be quite useful.
> > 
> > Is it a permanent addition to linux-next, is there a route to mainline, 
> > or something else?
> 
> Linus has said that he will not take the kvmtool tree in its 
> current form, but would prefer that it be a separate project, 
> so I should really drop it from linux-next (and ask the tip 
> guys to remove it from their auto-latest branch).
> 
> I have actually been meaning to get back to this, so, today I 
> will drop the kvmtool tree and, Ingo, if you could (at your 
> convenience i.e. when you are next rebasing it) remove it from 
> tip/auto-latest, thanks.

Pekka still intends to send it in the next merge window AFAIK, 
and I use it for testing rather frequently so I'm not going to 
remove it from my tree for the time being.

Note that I never actually had any maintenance problems due to 
it: it's orthogonal, and as long as you don't use it explicitly 
(such as its 'make kvmconfig' feature - which is rather handy) 
it never actually broke anything.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-06 21:46                         ` Ingo Molnar
@ 2013-02-06 21:55                           ` H. Peter Anvin
  2013-02-07 21:44                             ` Stephen Rothwell
  2013-02-07 21:40                           ` Stephen Rothwell
  1 sibling, 1 reply; 65+ messages in thread
From: H. Peter Anvin @ 2013-02-06 21:55 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, David Rientjes, Pekka Enberg, Linus Torvalds,
	Greg Kroah-Hartman, Sasha Levin, Randy Dunlap, David Woodhouse,
	Michal Marek, tglx, H. Peter Anvin, linux-kernel

On 02/06/2013 01:46 PM, Ingo Molnar wrote:
>>
>> Linus has said that he will not take the kvmtool tree in its 
>> current form, but would prefer that it be a separate project, 
>> so I should really drop it from linux-next (and ask the tip 
>> guys to remove it from their auto-latest branch).
>>
>> I have actually been meaning to get back to this, so, today I 
>> will drop the kvmtool tree and, Ingo, if you could (at your 
>> convenience i.e. when you are next rebasing it) remove it from 
>> tip/auto-latest, thanks.
> 
> Pekka still intends to send it in the next merge window AFAIK, 
> and I use it for testing rather frequently so I'm not going to 
> remove it from my tree for the time being.
> 
> Note that I never actually had any maintenance problems due to 
> it: it's orthogonal, and as long as you don't use it explicitly 
> (such as its 'make kvmconfig' feature - which is rather handy) 
> it never actually broke anything.
> 

So why don't we let Linus either accept and reject it for the 3.9 merge,
but it rejected, we drop it from linux-next until such time as Linus'
objections have been addressed?

	-hpa



^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-06 21:46                         ` Ingo Molnar
  2013-02-06 21:55                           ` H. Peter Anvin
@ 2013-02-07 21:40                           ` Stephen Rothwell
  2013-02-08 14:55                             ` Ingo Molnar
  1 sibling, 1 reply; 65+ messages in thread
From: Stephen Rothwell @ 2013-02-07 21:40 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: David Rientjes, Pekka Enberg, Linus Torvalds, Greg Kroah-Hartman,
	Sasha Levin, Randy Dunlap, David Woodhouse, Michal Marek,
	H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

Hi Ingo,

On Wed, 6 Feb 2013 22:46:46 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> Pekka still intends to send it in the next merge window AFAIK, 

That has been true since v3.2 :-(

> and I use it for testing rather frequently so I'm not going to 
> remove it from my tree for the time being.

I didn't ask you to remove it from your tree, I just would like it
removed from that branch that is included in linux-next
(tip/auto-latest).  I know others who also use it for testing.

> Note that I never actually had any maintenance problems due to 
> it: it's orthogonal, and as long as you don't use it explicitly 
> (such as its 'make kvmconfig' feature - which is rather handy) 
> it never actually broke anything.

I don't doubt any of that, it is just that Linus has explicitly said that
he will not pull it into his tree.  Thus, it should not be in linux-next.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-06 21:55                           ` H. Peter Anvin
@ 2013-02-07 21:44                             ` Stephen Rothwell
  0 siblings, 0 replies; 65+ messages in thread
From: Stephen Rothwell @ 2013-02-07 21:44 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Ingo Molnar, David Rientjes, Pekka Enberg, Linus Torvalds,
	Greg Kroah-Hartman, Sasha Levin, Randy Dunlap, David Woodhouse,
	Michal Marek, tglx, H. Peter Anvin, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

Hi,

On Wed, 06 Feb 2013 13:55:08 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> So why don't we let Linus either accept and reject it for the 3.9 merge,
> but it rejected, we drop it from linux-next until such time as Linus'
> objections have been addressed?

It has been in linux-next since before v3.2.  It has been submitted
multiple times.  Last October, after not accepting it for the v3.7 merge
window, Linus said:

"I have yet to see a compelling argument for merging it. It's tons of
code, it doesnt match the original "small simple" model, and I think
it would be better off as a separate project."

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-07 21:40                           ` Stephen Rothwell
@ 2013-02-08 14:55                             ` Ingo Molnar
  2013-02-08 21:14                               ` Linus Torvalds
  2013-02-19  8:08                               ` Ingo Molnar
  0 siblings, 2 replies; 65+ messages in thread
From: Ingo Molnar @ 2013-02-08 14:55 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Rientjes, Pekka Enberg, Linus Torvalds, Greg Kroah-Hartman,
	Sasha Levin, Randy Dunlap, David Woodhouse, Michal Marek,
	H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Ingo,
> 
> On Wed, 6 Feb 2013 22:46:46 +0100 Ingo Molnar <mingo@kernel.org> wrote:
> >
> > Pekka still intends to send it in the next merge window AFAIK, 
> 
> That has been true since v3.2 :-(

Yes, and it's improving rather nicely - but was not 
useful/interesting enough (yet) for Linus to pull.

So far it has over three dozen contributors, most of the commits 
come from active kernel developers.

> > and I use it for testing rather frequently so I'm not going 
> > to remove it from my tree for the time being.
> 
> I didn't ask you to remove it from your tree, I just would 
> like it removed from that branch that is included in 
> linux-next (tip/auto-latest).  I know others who also use it 
> for testing.

tip:master and tip:auto-latest are one and the same (with a time 
delay), so that I can merge faster to linux-next, and so that 
linux-next can benefit from the strong coverage testing of -tip.

> > Note that I never actually had any maintenance problems due 
> > to it: it's orthogonal, and as long as you don't use it 
> > explicitly (such as its 'make kvmconfig' feature - which is 
> > rather handy) it never actually broke anything.
> 
> I don't doubt any of that, it is just that Linus has 
> explicitly said that he will not pull it into his tree.  Thus, 
> it should not be in linux-next.

I'll remove it if Linus insists on it, but I think you guys are 
putting form before substance and utility :-(

tools/kvm/ is a useful utility to kernel development, that in 
just this past cycle was used as an incubator to:

  - port KVM functionality to a new architecture
  - port lockdep to user-space
  - test bzImages before booting them on real hardware

It was also used to prototype kernel features in the past. It's 
a project that is alive and useful.

While there's a metric ton of crap in the kernel, which is not 
useful to anyone, which has ongoing costs, and which nobody here 
complains about.

What harm has tools/kvm/ done to you?

I just checked, in the past it has not broken linux-next *once* 
- this current thread is about tools/kvm/ funcionality (for 
which Pekka has already applied the fix).

*Please* don't try to harm useful code just for the heck of it.

As long as the project keeps improving and as long as Pekka 
keeps trying his luck with the upstream merge in the next merge 
window, and as long as its benefits overweigh its costs, I see 
no reason not to include it - I am eating my own dog food.

Please stop this silliness, IMO it's not constructive at all ...

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-08 14:55                             ` Ingo Molnar
@ 2013-02-08 21:14                               ` Linus Torvalds
  2013-02-08 23:57                                 ` Pekka Enberg
  2013-02-19  8:08                               ` Ingo Molnar
  1 sibling, 1 reply; 65+ messages in thread
From: Linus Torvalds @ 2013-02-08 21:14 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, David Rientjes, Pekka Enberg,
	Greg Kroah-Hartman, Sasha Levin, Randy Dunlap, David Woodhouse,
	Michal Marek, H. Peter Anvin, Thomas Gleixner, H. Peter Anvin,
	Linux Kernel Mailing List

On Sat, Feb 9, 2013 at 1:55 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> I'll remove it if Linus insists on it, but I think you guys are
> putting form before substance and utility :-(

No. Your pull requests are just illogical. I have yet to see a single
reason why it should be merged.

I *thought* "ease of use" could be a reason, and then people posted
five-liner scripts to give some of the other virtual boxes the same
kind of interface.

Avoiding five lines of shell script is not a reason to pull a project
into the kernel.

> tools/kvm/ is a useful utility to kernel development, that in
> just this past cycle was used as an incubator to:

That's total bullshit.

It could be useful whether it is merged into the kernel or not.

"git" is a hell of a lot more useful utility for kernel development,
to the point that practically we couldn't do without it any more, and
it isn't merged into the kernel. It's a separate project with a
separate life, and it is *better* for it. The same goes for all the
tools that everybody uses every day for kernel development, often
without even thinking about them.

So "utility to kernel development" is not a reason for merging it into
the kernel. NOT AT ALL.

> *Please* don't try to harm useful code just for the heck of it.

Again, total *bullshit*. Right now, the whole "attach the kvmtool to
the kernel as a remora" doesn't make any sense at all, and not merging
it doesn't harm anything AT ALL. Quite the reverse.

The fact that kvmtool isn't available as a standalone project probably
keeps people actively from using it. You can't just fetch kvmtool. You
have to fetch the kernel and kvmtool, and if you're a kernel developer
you either have to make a whole new kernel tree for it (which is
stupid) or merge it into your normal kernel tree that has development
that has nothing to do with kvmtool (which is stupid AND F*CKING
INSANE)

> Please stop this silliness, IMO it's not constructive at all ...

Ingo, it's not us being silly, it is *you*.

What the heck is the advantage of merging it into the kernel? It has
never ever been explained.

This is not like "perf", where there wasn't any alternatives, and
oprofile had shown over many many years that the situation wasn't
improving: it was only getting worse, and more disconnected from the
actual capabilities of the hardware.

But kvmtool is no "perf". There are other virtual boxes, and rather
than being limited, they are more capable! The selling tool of kvmtool
was never that it did something particularly magical, it was always
that it did less, and was easier to use. But that does not in any way
mean "should be merged". You can do less and be easier to use and
stand on your own legs.

So here, let me state it very very clearly: I will not be merging
kvmtool. It's not about "useful code". It's not about the project
keeping to improve. Both of those would seem to be *better* outside
the kernel, where there isn't that artificial and actually harmful
tie-in.

In other words, I don't see *any* advantage to merging kvmtool. I
think merging it would be an active mistake, and would just tie two
projects together that just shouldn't be tied together.

So nobody is "hurting useful code", except perhaps you.

Explain to me why I'm wrong. I don't think you can. You certainly
haven't so far.

               Linus

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-08 21:14                               ` Linus Torvalds
@ 2013-02-08 23:57                                 ` Pekka Enberg
  2013-02-09  0:45                                   ` Linus Torvalds
  0 siblings, 1 reply; 65+ messages in thread
From: Pekka Enberg @ 2013-02-08 23:57 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Ingo Molnar, Stephen Rothwell, David Rientjes,
	Greg Kroah-Hartman, Sasha Levin, Randy Dunlap, David Woodhouse,
	Michal Marek, H. Peter Anvin, Thomas Gleixner, H. Peter Anvin,
	Linux Kernel Mailing List

Linus,

I'm going to go out on a limb here and say that this might the odd out
case that's not really supposed to happen where *you* are just WRONG,
CRAZY, and IGNORING REALITY.

On Fri, Feb 8, 2013 at 11:14 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> I think merging it would be an active mistake, and would just tie two
> projects together that just shouldn't be tied together.

The two are already tied together - that was the whole premise of the
project!

What Ingo proposed two years ago was to implement a (simple) userspace
counterpart of KVM under tools/kvm using kernel development process
and reusing kernel code as much as possible. He predicted that we'd
eventually have:

  - a clean codebase that's accessible to new developers

  - new kernel features developed in 'lock-step' with the userspace code

  - encouraged kernel developers to write userspace code

As it turns out, Ingo's predictions were correct. We support KVM on
ARMv8 even before the in-kernel code has hit mainline. People
implemented vhost drivers in lock-step. Most of the contributors are
also kernel developers. And we in fact have a clean codebase that's
accessible to anyone who knows the kernel coding style.

I honestly don't see any of these things happening had we not taken the
path suggested by Ingo early on.

On Fri, Feb 8, 2013 at 11:14 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> The fact that kvmtool isn't available as a standalone project probably
> keeps people actively from using it. You can't just fetch kvmtool. You
> have to fetch the kernel and kvmtool, and if you're a kernel developer
> you either have to make a whole new kernel tree for it (which is
> stupid) or merge it into your normal kernel tree that has development
> that has nothing to do with kvmtool (which is stupid AND F*CKING
> INSANE)

Actually, as a kernel developer, you don't need to do that. You can
'make install' from a kvmtool branch and leave it at that - just like
with perf. [ And if it was in your tree, you'd wouldn't even need the
branch ;-). ]

And yes, you are absolutely correct that living in the kernel tree is
suboptimal for the casual user. However, it's a trade-off to make
tools/kvm *development* easier especially when you need to touch both
kernel and userspace code.

On Fri, Feb 8, 2013 at 11:14 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> "git" is a hell of a lot more useful utility for kernel development,
> to the point that practically we couldn't do without it any more, and
> it isn't merged into the kernel. It's a separate project with a
> separate life, and it is *better* for it.

Sure but the difference between "git" and kvmtool is that a significant
chuck of kvmtool development is directly related to in-kernel KVM and
device drivers. That's why I've argued from day one that tools/kvm is
'special'.

			Pekka

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-08 23:57                                 ` Pekka Enberg
@ 2013-02-09  0:45                                   ` Linus Torvalds
  2013-02-09 10:01                                     ` Pekka Enberg
  0 siblings, 1 reply; 65+ messages in thread
From: Linus Torvalds @ 2013-02-09  0:45 UTC (permalink / raw)
  To: Pekka Enberg
  Cc: Ingo Molnar, Stephen Rothwell, David Rientjes,
	Greg Kroah-Hartman, Sasha Levin, Randy Dunlap, David Woodhouse,
	Michal Marek, H. Peter Anvin, Thomas Gleixner, H. Peter Anvin,
	Linux Kernel Mailing List

On Sat, Feb 9, 2013 at 10:57 AM, Pekka Enberg <penberg@kernel.org> wrote:
>
> And yes, you are absolutely correct that living in the kernel tree is
> suboptimal for the casual user. However, it's a trade-off to make
> tools/kvm *development* easier especially when you need to touch both
> kernel and userspace code.

Quite frankly, that's just optimizing for the wrong case.

The merged case seems to make sense for you and Ingo, and nobody else.

And then you wonder why nobody else wants to merge it.

I've told you my reasons, you didn't give me *any* actual reasons for
me to merge the code. NONE of your statements made any sense at all,
since everything you talk about could have been done with a separate
project.

The only thing the lock-step does is to generate the kind of
dependency that I ABSOLUTELY DETEST, where one version of kvmtools
goes along with one version of the kernel. That's a huge disadvantage
(and we've actually seen signs of that in the perf tool too, where old
versions of the tools have been broken, because the people working on
them have been way too much in lock-step with the kernel it is used
on).

And if it's not the case that they have to be used in lockstep, then
clearly kvmtool developers could just as easily just have a separate
git repository.

So you can't have it both ways. What's so wrong with just making it a
separate project?

                  Linus

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-09  0:45                                   ` Linus Torvalds
@ 2013-02-09 10:01                                     ` Pekka Enberg
  2013-02-09 18:07                                       ` Linus Torvalds
  0 siblings, 1 reply; 65+ messages in thread
From: Pekka Enberg @ 2013-02-09 10:01 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Ingo Molnar, Stephen Rothwell, David Rientjes,
	Greg Kroah-Hartman, Sasha Levin, Randy Dunlap, David Woodhouse,
	Michal Marek, H. Peter Anvin, Thomas Gleixner, H. Peter Anvin,
	Linux Kernel Mailing List

On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> Quite frankly, that's just optimizing for the wrong case.

I obviously don't agree. I'm fairly sure there wouldn't be a kvmtool
that supports x86, PPC64, ARM, and all the virtio drivers had we not
optimized for making development for kernel folks easy.

In fact that's something Ingo pushed for pretty hard early on and we
also worked hard just to make the code 'feel familiar' to kernel folks.
The assumption was that if we did that, we'd see contributions from
people who would normally not write userspace code.

On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> The merged case seems to make sense for you and Ingo, and nobody else.

That's hardly surprising. I'm the only person who was crazy enough to
listen to Ingo and follow through with the damn thing. So I either have
the same experience and perspective as Ingo does on the matter - or I'm
just as full of 'bullshit' as he is.

On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> The only thing the lock-step does is to generate the kind of
> dependency that I ABSOLUTELY DETEST, where one version of kvmtools
> goes along with one version of the kernel.

That is simply NOT TRUE. We have never done such a thing with 'kvmtool'
nor I have any evidence that 'perf' has done that either. I regularily
run old versions to make sure that we stay that way.

On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> So you can't have it both ways. What's so wrong with just making it a
> separate project?

Do you really think it's an option I have not considered several times?

There are the immediate practical problems:

  - What code should we take with us from the Linux repository. If I take
    just tools/kvm, it won't even build.

  - Where do we do our development? Right now we are using the KVM list
    and are part of tip tree workflow. As a separate project, we need to
    build the kind of infrastructure we already are relying on now.

Then there are the long term issues:

  - How do we keep up with KVM and virtio improvements?

  - How do we ensure we get improvements that happened in the kernel
    tree to our codebase for the code we share?

  - How do we make it easy for future KVM and virtio developers to
    access our code?

If you want perspective on this just ask Ingo sometime how he feels
about making tools/perf a separate project (which I have actually done).
Much of the *practical* aspects applies to tools/kvm.

And really, I'm a practical kind of guy. Why do you think I'm willing to
bang to my head to the wall if spinning off as a separate project would
be as simple as you seem to think it is?

			Pekka

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-09 10:01                                     ` Pekka Enberg
@ 2013-02-09 18:07                                       ` Linus Torvalds
  2013-02-09 19:39                                         ` Pekka Enberg
  0 siblings, 1 reply; 65+ messages in thread
From: Linus Torvalds @ 2013-02-09 18:07 UTC (permalink / raw)
  To: Pekka Enberg
  Cc: Linux Kernel Mailing List, H. Peter Anvin, Randy Dunlap,
	Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell, Ingo Molnar

You do realize that none of your arguments touched the "why should
Linus merge the tree" question at all?

Everything you said was about how it's more convenient for you and
Ingo, not at all about why it should be better for anybody else. You
haven't bothered to even try making it an external project, so it
doesn't compile that way. You're the only one working on it, so being
convenient for you is the primary issue. Arguments like that actively
make me not want to merge it, because they are only arguments for you
continuing to work the way you have, not arguments for why the project
would make sense to merge into the main kernel repository.

So I think we should just remove this from linux-next, and be done
with the fantasy that it makes sense to merge this. You're not even
trying to convince anybody else about the merge making sense.

You might as well continue to work the way you do, and I don't mind -
but none of it argues for me merging it into the kernel. There's no
reason why kvmtool couldn't be external the way all the other
virtualization projects are.

             Linus

On Feb 9, 2013 2:01 AM, "Pekka Enberg" <penberg@kernel.org> wrote:
>
> On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > Quite frankly, that's just optimizing for the wrong case.
>
> I obviously don't agree. I'm fairly sure there wouldn't be a kvmtool
> that supports x86, PPC64, ARM, and all the virtio drivers had we not
> optimized for making development for kernel folks easy.
>
> In fact that's something Ingo pushed for pretty hard early on and we
> also worked hard just to make the code 'feel familiar' to kernel folks.
> The assumption was that if we did that, we'd see contributions from
> people who would normally not write userspace code.
>
> On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > The merged case seems to make sense for you and Ingo, and nobody else.
>
> That's hardly surprising. I'm the only person who was crazy enough to
> listen to Ingo and follow through with the damn thing. So I either have
> the same experience and perspective as Ingo does on the matter - or I'm
> just as full of 'bullshit' as he is.
>
> On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > The only thing the lock-step does is to generate the kind of
> > dependency that I ABSOLUTELY DETEST, where one version of kvmtools
> > goes along with one version of the kernel.
>
> That is simply NOT TRUE. We have never done such a thing with 'kvmtool'
> nor I have any evidence that 'perf' has done that either. I regularily
> run old versions to make sure that we stay that way.
>
> On Sat, Feb 9, 2013 at 2:45 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > So you can't have it both ways. What's so wrong with just making it a
> > separate project?
>
> Do you really think it's an option I have not considered several times?
>
> There are the immediate practical problems:
>
>   - What code should we take with us from the Linux repository. If I take
>     just tools/kvm, it won't even build.
>
>   - Where do we do our development? Right now we are using the KVM list
>     and are part of tip tree workflow. As a separate project, we need to
>     build the kind of infrastructure we already are relying on now.
>
> Then there are the long term issues:
>
>   - How do we keep up with KVM and virtio improvements?
>
>   - How do we ensure we get improvements that happened in the kernel
>     tree to our codebase for the code we share?
>
>   - How do we make it easy for future KVM and virtio developers to
>     access our code?
>
> If you want perspective on this just ask Ingo sometime how he feels
> about making tools/perf a separate project (which I have actually done).
> Much of the *practical* aspects applies to tools/kvm.
>
> And really, I'm a practical kind of guy. Why do you think I'm willing to
> bang to my head to the wall if spinning off as a separate project would
> be as simple as you seem to think it is?
>
>                         Pekka

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-09 18:07                                       ` Linus Torvalds
@ 2013-02-09 19:39                                         ` Pekka Enberg
  2013-02-09 19:57                                           ` Linus Torvalds
  0 siblings, 1 reply; 65+ messages in thread
From: Pekka Enberg @ 2013-02-09 19:39 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, H. Peter Anvin, Randy Dunlap,
	Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell, Ingo Molnar

On Sat, Feb 9, 2013 at 8:07 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> Everything you said was about how it's more convenient for you and
> Ingo, not at all about why it should be better for anybody else. You
> haven't bothered to even try making it an external project, so it
> doesn't compile that way. You're the only one working on it, so being
> convenient for you is the primary issue. Arguments like that actively
> make me not want to merge it, because they are only arguments for you
> continuing to work the way you have, not arguments for why the project
> would make sense to merge into the main kernel repository.

You are so full of shit it's not even funny.

I am *not* the only person working on the project, far from it. I'm not
trying to make things easy for me, I'm trying to build on the strenghts
of tools/kvm.

The main argument for merging into the main kernel repository has always been
that (we think) it improves the kernel because significant amount of
development is directly linked to kernel code (think KVM ARM port here, for
example). The secondary argument has been to make it easy for kernel developers
to work on both userspace and kernel in tandem (like has happened with vhost
drivers). In short: it speeds up development of Linux virtualization code.

It's not as if there's anything new here so I didn't think it was
necessary to rehash the old arguments. I know you don't have a
compelling reason to pull and that's fine. Just don't come up with these
lame excuses that have nothing to do with reality.

			Pekka

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-09 19:39                                         ` Pekka Enberg
@ 2013-02-09 19:57                                           ` Linus Torvalds
  2013-02-09 21:06                                             ` Theodore Ts'o
  2013-02-11 12:26                                             ` Ingo Molnar
  0 siblings, 2 replies; 65+ messages in thread
From: Linus Torvalds @ 2013-02-09 19:57 UTC (permalink / raw)
  To: Pekka Enberg
  Cc: Linux Kernel Mailing List, H. Peter Anvin, Randy Dunlap,
	Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell, Ingo Molnar

On Sun, Feb 10, 2013 at 6:39 AM, Pekka Enberg <penberg@kernel.org> wrote:
>
> The main argument for merging into the main kernel repository has always been
> that (we think) it improves the kernel because significant amount of
> development is directly linked to kernel code (think KVM ARM port here, for
> example). The secondary argument has been to make it easy for kernel developers
> to work on both userspace and kernel in tandem (like has happened with vhost
> drivers). In short: it speeds up development of Linux virtualization code.

Why? You've made this statement over and over and over again, and I've
dismissed it over and over and over again because I simply don't think
it's true.

It's simply a statement with nothing to back it up. Why repeat it?

THAT is my main contention. I told you why I think it's actually
actively untrue. You claim it helps, but what is it about kvmtool that
makes it so magically helpful to be inside the kernel repository? What
is it about this that makes it so critical that you get the kernel and
kvmtool with a single pull, and they have to be in sync? When you then
at the same time claim that you make very sure that they don't have to
be in sync at all. See your earlier emails about how you claim to have
worked very hard to make sure they work across different versions.

So you make these unsubstantiated claims about how much easier it is,
and they make no sense. You never explain *why* it's so magically
easier. Is git so hard to use that you can't do "git pull" twice? And
why would you normally even *want* to do git pull twice? 99% of the
work in the kernel has nothing what-so-ever to do with kvmtool, and
hopefully the reverse is equally true.

And tying into the kernel just creates this myopic world of only
looking at the current kernel. What if somebody decides that they
actually want to try to boot Windows with kvmtool? What if somebody
tells you that they are really tired of Xen, and actually want to turn
kvmtool into  *replacement* for Xen instead? What if somebody wants to
branch off their own work, concentrating on some other issue entirely,
and wants to merge with upstream kvmtool but not worry about the
kernel, because they aren't working on the Linux kernel at all, and
their work is about something else?

I just don't think it makes sense. I don't see what the huge advantage
of a single git tree is.

Anyway, I'm done arguing. You can do what you want, but just stop
misrepresenting it as being "linux-next" material unless you are
willing to actually explain why it should be so.

                Linus

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-09 19:57                                           ` Linus Torvalds
@ 2013-02-09 21:06                                             ` Theodore Ts'o
  2013-02-11 12:38                                               ` Ingo Molnar
  2013-02-11 12:26                                             ` Ingo Molnar
  1 sibling, 1 reply; 65+ messages in thread
From: Theodore Ts'o @ 2013-02-09 21:06 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Pekka Enberg, Linux Kernel Mailing List, H. Peter Anvin,
	Randy Dunlap, Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell, Ingo Molnar

On Sun, Feb 10, 2013 at 06:57:41AM +1100, Linus Torvalds wrote:
> THAT is my main contention. I told you why I think it's actually
> actively untrue. You claim it helps, but what is it about kvmtool that
> makes it so magically helpful to be inside the kernel repository? What
> is it about this that makes it so critical that you get the kernel and
> kvmtool with a single pull, and they have to be in sync? When you then
> at the same time claim that you make very sure that they don't have to
> be in sync at all. See your earlier emails about how you claim to have
> worked very hard to make sure they work across different versions.

I completely agree with Linus here; in fact, the main reason why it's
important to keep userspace tools outside of the kernel is that it
keeps us careful about interface design.

For example, I consider it a *feature* that when we extend the file
system data structures for ext4, they have to be made in the two
places; once in the kernel, and once in e2fsprogs's version of
ext2_fs.h.  Yes, it might be more convenient if we pushed all of
e2fsprogs into the kernel, so I wouldn't have to edit ext2_fs.h in two
places, but when I make changes to ext2_fs.h, I want to be really
careful, lest I not break backwards compatibility, and to think very
carefully about forward compatibility issues.

If there are constantly huge numbers of interface changes in the
kernel/userspace interface, then it increases the chances that
mistakes will be made.  It's better that those mistakes be caught
early, and if changes need to be made in two places, it increases the
chances that these mistakes will be noticed sooner rather than later.

	     	   	    	    	    - Ted

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-09 19:57                                           ` Linus Torvalds
  2013-02-09 21:06                                             ` Theodore Ts'o
@ 2013-02-11 12:26                                             ` Ingo Molnar
  2013-02-11 12:56                                               ` Ingo Molnar
                                                                 ` (2 more replies)
  1 sibling, 3 replies; 65+ messages in thread
From: Ingo Molnar @ 2013-02-11 12:26 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Pekka Enberg, Linux Kernel Mailing List, H. Peter Anvin,
	Randy Dunlap, Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sun, Feb 10, 2013 at 6:39 AM, Pekka Enberg <penberg@kernel.org> wrote:
> >
> > The main argument for merging into the main kernel 
> > repository has always been that (we think) it improves the 
> > kernel because significant amount of development is directly 
> > linked to kernel code (think KVM ARM port here, for 
> > example). The secondary argument has been to make it easy 
> > for kernel developers to work on both userspace and kernel 
> > in tandem (like has happened with vhost drivers). In short: 
> > it speeds up development of Linux virtualization code.
> 
> Why? You've made this statement over and over and over again, 
> and I've dismissed it over and over and over again because I 
> simply don't think it's true.
> 
> It's simply a statement with nothing to back it up. Why repeat 
> it?
> 
> THAT is my main contention. I told you why I think it's 
> actually actively untrue. You claim it helps, but what is it 
> about kvmtool that makes it so magically helpful to be inside 
> the kernel repository? What is it about this that makes it so 
> critical that you get the kernel and kvmtool with a single 
> pull, and they have to be in sync? [...]

If you are asking whether it is critical for the kernel project 
to have tools/kvm/ integrated then it isn't. The kernel will 
live just fine without it, even if that decision is a mistake.

[ In hindsight not taking the GGI code 15+ years ago was IMO a 
  (bad) mistake - yet we lived. ]

I think it's actively *useful* to the kernel project to have 
tools/kvm/ - because we already reaped some benefits and have
the commit IDs to prove it.

If you are asking why it is helpful to the tools/kvm project to 
be part of the kernel repository then there's plenty of (good) 
reasons as well. (And because it's the much smaller project, the 
benefits are much more significant to it than benefits are to 
the Linux kernel project, relatively. You'll find that to be 
true with just about any code.)

Is any of those reasons of why it's good for tools/kvm/ to be in 
the kernel repo critical? I think the *combination* is 
definitely critical. It's very much possible for each factor to 
seem 'small' in isolation but for the combination to be 
significant - denying that would be fallacy of composition.

Let me list them in case there's anything new that was not said 
before. Some of the advantages are social, some are technical:

1) 'tooling and kernel side support goes hand in hand'

I can best describe this from the tools/perf/ perspective: 
reviewing new kernel side features that has tooling impact is a 
*LOT* easier and a lot faster if it comes with readable, 
functional tooling patches.

There's no ifs and whens about it, and that alone makes 
tools/perf/ worth it to such a degree that we imposed a 
maintenance rule so that kernel side features always need to 
come with enabling tooling support.

With tools/kvm/ I saw similar effects as well - on a smaller 
scale, because due to not being upstream tools/kvm/ cannot 
realistically improve upon ABIs nearly as well as tools/perf/ 
can. Those effects will strengthen as the project grows.

For tools/kvm/ this property is optional, so unlike tools/perf/ 
you don't see it for every activity there - but there were 
several examples of that despite its optionality.

2) 'code reuse'

We utilize useful kernel code directly in user-space. It starts 
out ad-hoc and messy (and I still like Al Viro's description of 
that process back from the tools/perf/ flamewars).

We have a tools/kvm/ example of that process in action: for 
example an upcoming v3.9 feature, the user-space lockdep utility 
enabled via tools/lib/lockdep/. (Although now you might NAK 
that, I don't really understand your underlying position here.)

I am pretty confident to say that the new liblockdep and the 
'lockdep' utility (which checks pthread_mutex and pthread_rwlock 
locking in user-space - on existing binaries, using LD_PRELOAD), 
despite having been talked about for years, would simply not 
have happened without tools/kvm/ present in a kernel repo, full 
stop.

Not this year, not next year, probably not this decade. The 
reason is that the code needed several unlikely constellations 
to coincide:

 - tools/kvm attracted a capable contributor who never wrote
   kernel code before but who was interested in user-space
   coding and in virtualization code.

 - this person, over the past 2 years, learned the ropes and 
   gradually started writing kernel code as well.

 - he also learned how to interact tooling with the kernel
   proper. First the messy way, then in gradually less messy
   ways.

 - tools/kvm/ uses a user-space equivalent of kernel locking 
   primitives, such a mutex_lock()/mutex_unlock(), so his 
   experience with tools/kvm/ locking helped him kick-start 
   into looking at kernel-side locking.

 - he got to the level where he would understand lockdep.c,
   a pretty non-trivial piece of kernel code.

 - he ended up gradually validating whether lockdep could be 
   ported to user-space. He first used 'messy' integration: 
   kernel/lockdep.c hacked up badly and linked directly into 
   user-space app. Then he did 'clean' integration: some 
   modifications to kernel/lockdep.c enabled it to be 
   librarified, and then the remaining work was done in 
   user-space - here too in successive steps.

 - tools/kvm/ happened to be hosted in the same kernel repo
   that the locking tree is hosted in.

The end result is something good that I never saw happen to 
kernel code before, in the last 20 years of the Linux kernel. 
Maybe it could have happened with an outside tools/kvm repo, but 
I very strongly suspect that it would not.

In theory this could have been done in the cold, fragmented, 
isolated and desolate landscape of Linux user-space utilities, 
by copying kernel/lockdep.c and a handful of kernel headers to 
user-space, and making it work there somehow.

Just like a blue rose could in theory grow on Antarctica as 
well, given the right set of circumstances. It just so happens 
that blue roses best grow in Holland, where there's good support 
infrastructure for growing green stuff, while you'd have to look 
hard to find any green stuff at all on Antarctica.

Now is user-space lockdep something fundamental and important?

I think it's not critical in terms of technology (any of us can 
only do small code changes really), but having a new breed of 
contributors who are good at both kernel and user-space coding, 
and who do that as part of a single contribution community, is 
both refreshing and potentially important.

[ Obviously I'm seeing similar goodness in tools/perf/ as well, 
  and forcing it to split off from the kernel repo would be a 
  sad step backwards. ]

3) 'trust, distribution, testing, ease of use'

I personally tend to install a single Git tree on a test machine 
when testing the kernel: a single kernel repo. I keep that one 
updated, it's the only variable factor on that box - I don't 
change /etc/ if I can avoid it and I don't install packages and 
don't build utilities from source.

Any utility I rely on either comes with the kernel proper, or is 
already installed on the box (potentially 5 years old) - or does 
not get updated (or used much). Yes, I could clone utility Git 
repositories - but there's a barrier of usage due to several 
factors:

 - I'd have to figure out which Git repo to pull and whether to 
   trust it. I know I can generally trust the kernel repo so I 
   don't mind about doing a 'make install' there as root.

 - I'd have to make sure that the Git repo is really the latest 
   and current one of that utility. If I really only need that 
   utility marginally, why should I bother?

 - I know how to build and install it, because it follows 
   similar principles.

 - I know how to fix and enhance it, should I feel the need,
   by using the established kernel community contribution 
   infrastructure.

 - Several of my test boxes have old distros for compatibility 
   testing, where package updates and install don't work anymore 
   because all the URIs broke already, years ago. So installing 
   from source is the only option to get a recent utility.

The kernel repo gives me a single reference of 'trusted and up 
to date' stuff I need for kernel development. I only have to 
update it once and I know it's all uptodate and relevant.

If you look at any of these factors in isolation it feels small 
and borderline. In combination it's compelling to me.

Could I install a utility via distro packaging or via pulling 
another Git tree? Possibly, but see the barriers above.

4) 'We get maintenance culture imposed'

The kernel project basically offers a template and an 
enforcement mechanism. It is a very capable incubator for 
smaller projects, and I think that's a very good and useful 
thing.

I'm not aware of any similar incubators - the utility landscape 
is sadly very fragmented, with no meta project that holds it 
together, and we are hurting from that.

Could an outside project enforce the same maintenance culture? 
Only if the maintainer is very good and is doing it for the 
whole life-time of the project - and even then it would be done 
at an increased cost - right now we can just piggy back to the 
existing kernel project contribution quality rules.

In practice I've seen plenty of projects that started out good 
and then years down the road entropy ate their quality.

Too much freedom to mess up and all that - sharing 
infrastructure by related projects is good in most cases, why do 
we have to *insist* on projects to live separately and isolated?

5) 'We get to be a (minor) part of a larger, already established 
    community.'

Barriers of entry and barriers of progress are much lower within 
a single project.

Furthermore, if you are a contributor who *disagrees* with the 
concept of a cold, fragmented, inefficient and unproductive 
Linux utilities landscape that lacks a meta project framework to 
insert sanity then it's only natural to desire to be part of a 
sane project and not create yet another new, isolated project.

[ As the leader of the larger project you are obviously fully
  within your rights to reject community membership, if you feel 
  the code is harmful or just not useful enough. ]

> [...] When you then at the same time claim that you make very 
> sure that they don't have to be in sync at all. See your 
> earlier emails about how you claim to have worked very hard to 
> make sure they work across different versions.

I don't think there's any contradiction, the two concepts are 
not exclusive, it's similar to tools/perf/:

It's *very* useful to have integration, in terms of improving 
the various conditions for contribution and in terms of enabling 
code to flow efficiently both into the kernel and into tooling.

But it's not *required*, we obviously want ABI compatibility, 
want older versions to still work, etc.

So suggesting that there's a contradiction is a false dichotomy.

> So you make these unsubstantiated claims about how much easier 
> it is, and they make no sense. You never explain *why* it's so 
> magically easier. Is git so hard to use that you can't do "git 
> pull" twice? And why would you normally even *want* to do git 
> pull twice? 99% of the work in the kernel has nothing 
> what-so-ever to do with kvmtool, and hopefully the reverse is 
> equally true.

The target user base of tools/kvm/ is developers. If my personal 
experience as a tester/user of utilities in a heterogenous test 
environment matters to you:

I think the only non-kernel Git repo I ever pulled to a test box 
was the Git repo - and that was not voluntary, a 5 years old Git 
binary broke on the test box so I had to rebuild it.

I don't pull them because I had bad experience with most of 
them: they create /etc footprint that might interact with the 
validity of my ongoing testing (I try to keep installations 
pristine), quite a few of them simply don't compile on older 
systems, and they are also rather dissimilar in terms of how to 
build, install & run them. (I also find it a bit sisyphean to 
put effort into a utilities model that I don't think works very 
well.)

> And tying into the kernel just creates this myopic world of 
> only looking at the current kernel. What if somebody decides 
> that they actually want to try to boot Windows with kvmtool?

IIRC Windows support for kmvtool is work in progress - some 
patches already got applied.

Is Windows support a no-no for the Linux kernel repo?

> What if somebody tells you that they are really tired of Xen, 
> and actually want to turn kvmtool into *replacement* for Xen 
> instead? [...]

Actually, this was raised by some people - and I think some 
generalization patches were applied already but Pekka might know 
more about that ...

> [...] What if somebody wants to branch off their own work, 
> concentrating on some other issue entirely, and wants to merge 
> with upstream kvmtool but not worry about the kernel, because 
> they aren't working on the Linux kernel at all, and their work 
> is about something else?

I'm not sure I understand this question - tools/kvm/ only runs 
on a Linux kernel host, rather fundamentally, by using the (very 
Linux specific) KVM syscalls.

Hypothetically, if some other OS offered full KVM syscall 
compatibility and would start driving KVM development, then 
tools/kvm/ could accept patches related to that.

As long as the code is clean I see no problems, it would even be 
good because it might help put new features into KVM, should 
that 'other OS' improve upon the KVM syscalls. In terms of 
tools/kvm/ development we'd still think of that other OS as some 
Linux fork in essence.

So I'm not sure I fully understood this particular concern of 
yours.

Are you thinking about what happens if Linux itself dies down 
and gets replaced by some other OS, dragging down 'hosted' code 
with it? That would be very disruptive to a whole lot of other 
code as well, such as more obscure drivers, filesystems and 
kernel features that are currently only present in Linux - all 
of which would eventually find a new home with the new king OS, 
with different levels of costs of porting.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-09 21:06                                             ` Theodore Ts'o
@ 2013-02-11 12:38                                               ` Ingo Molnar
  0 siblings, 0 replies; 65+ messages in thread
From: Ingo Molnar @ 2013-02-11 12:38 UTC (permalink / raw)
  To: Theodore Ts'o, Linus Torvalds, Pekka Enberg,
	Linux Kernel Mailing List, H. Peter Anvin, Randy Dunlap,
	Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell


* Theodore Ts'o <tytso@mit.edu> wrote:

> I completely agree with Linus here; in fact, the main reason 
> why it's important to keep userspace tools outside of the 
> kernel is that it keeps us careful about interface design.

We have first hand experience there: tools/perf/.

None of the predicted extreme badness happened. Yes, sometimes 
we broke compatibility as ABI changes/enhancements do - but 
treated them as regressions and fixed them. I also think that 
considering the rate of changes our breakage ratio is very good.

So no badness happened, and in fact a lot of goodness happened: 
which goodness never happened while Linux profiling was a 
separate project isolated as a user-space utility!

Anyone opposing integration I think *HAS* to explain the 
mechanics behind this very example in plain sight.

Why the heck has pretty much every other out of tree profiling 
project died, while the in-tree one is thriving?

Yes, the key is that Arnaldo is good, and so are the other perf 
contributors - and they are good because they feel at home and 
they are productive. Being in the kernel repo is actually 90% 
responsible for that environment!

> For example, I consider it a *feature* that when we extend the 
> file system data structures for ext4, [...]

I consider filesystems the most extreme example. It's so extreme 
that it's almost a separate class for itself.

Filesystems have the most extreme data persistency constraints 
possible: they define the ABI and anything that gets written out 
through them to persistent storage stays there forever and has 
to work, years down the line. So one must be absolutely, 110% 
careful - to the level of inventing new validation technologies 
just to be more careful.

*NONE* of that applies to tools/perf/ or tools/kvm/: neither 
really writes any data structure defined by itself that will be 
persistent forever. perf.data comes closest, but when was it the 
last time you used a year old perf.data? I'd say never. It 
either gets used within a few days or does not get used at all.

( Yet we even keep perf.data compatibility because being careful 
  about data is generally good technology - it's just not 
  *critical*. )

Same goes for tools/kvm/: it has very short data persistency 
latency as well. Such are in fact most other kernel related 
utilities.

So your 'filesystem utilities' example is totally inapplicable 
to tools/perf/ and tools/kvm/. Shaping all utilities based on 
that extreme example is a sad mistake.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-11 12:26                                             ` Ingo Molnar
@ 2013-02-11 12:56                                               ` Ingo Molnar
  2013-02-11 13:18                                                 ` David Woodhouse
  2013-02-11 14:47                                               ` Pekka Enberg
  2013-02-11 16:32                                               ` Linus Torvalds
  2 siblings, 1 reply; 65+ messages in thread
From: Ingo Molnar @ 2013-02-11 12:56 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Pekka Enberg, Linux Kernel Mailing List, H. Peter Anvin,
	Randy Dunlap, Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell


* Ingo Molnar <mingo@kernel.org> wrote:

> [...]
>
>  - he ended up gradually validating whether lockdep could be 
>    ported to user-space. He first used 'messy' integration: 
>    kernel/lockdep.c hacked up badly and linked directly into 
>    user-space app. Then he did 'clean' integration: some 
>    modifications to kernel/lockdep.c enabled it to be 
>    librarified, and then the remaining work was done in 
>    user-space - here too in successive steps.
> 
>  - tools/kvm/ happened to be hosted in the same kernel repo
>    that the locking tree is hosted in.
> 
> The end result is something good that I never saw happen to 
> kernel code before, in the last 20 years of the Linux kernel. 
> Maybe it could have happened with an outside tools/kvm repo, 
> but I very strongly suspect that it would not.
> 
> In theory this could have been done in the cold, fragmented, 
> isolated and desolate landscape of Linux user-space utilities, 
> by copying kernel/lockdep.c and a handful of kernel headers to 
> user-space, and making it work there somehow.
> 
> Just like a blue rose could in theory grow on Antarctica as 
> well, given the right set of circumstances. It just so happens 
> that blue roses best grow in Holland, where there's good 
> support infrastructure for growing green stuff, while you'd 
> have to look hard to find any green stuff at all on 
> Antarctica.

To use another, perhaps more applicable analogy:

If one has the choice to start a new business in the U.S., it 
would be reasonable to do that. There's a lot of supporting 
infrastructure, trust, distribution, standards, enforcement 
agencies and available workers.

Could the same business succeed in Somalia as well? Possibly - 
if it's a bakery or something similarly fundamental. More 
complex businesses would likely not thrive very well there.

*That* is how I think the current Linux kernel tooling landscape 
looks like currently in a fair number of places: in many aspects 
it's similar to Somalia - disjunct entities with not much 
commonality or shared infrastructure.

Why people question the desire for a kernel related project 
(that only runs on a Linux host) to actually be part of an 
already well working, civilized society (the kernel repo) - for 
mutual, well documented benefits - instead of having to grow it 
all itself, is rather perplexing to me...

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-11 12:56                                               ` Ingo Molnar
@ 2013-02-11 13:18                                                 ` David Woodhouse
  2013-02-11 13:58                                                   ` Anca Emanuel
                                                                     ` (2 more replies)
  0 siblings, 3 replies; 65+ messages in thread
From: David Woodhouse @ 2013-02-11 13:18 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, Pekka Enberg, Linux Kernel Mailing List,
	H. Peter Anvin, Randy Dunlap, Thomas Gleixner, David Rientjes,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

On Mon, 2013-02-11 at 13:56 +0100, Ingo Molnar wrote:
> To use another, perhaps more applicable analogy:
> 
> If one has the choice to start a new business in the U.S., it 
> would be reasonable to do that. There's a lot of supporting 
> infrastructure, trust, distribution, standards, enforcement 
> agencies and available workers.
> 
> Could the same business succeed in Somalia as well? Possibly - 
> if it's a bakery or something similarly fundamental. More 
> complex businesses would likely not thrive very well there.
> 
> *That* is how I think the current Linux kernel tooling landscape 
> looks like currently in a fair number of places: in many aspects 
> it's similar to Somalia - disjunct entities with not much 
> commonality or shared infrastructure.

That's complete nonsense. If you want to use pieces of the kernel
infrastructure, then just *take* them. There are loads of projects which
use the kernel config tools, for example. There's no need to be *in* the
kernel repo.

And for code-reuse it's even easy enough to automatically extract parts
of kernel code into a separate repository. See the ecos-jffs2 and
linux-headers trees, for example, which automatically tracked Linus'
tree with a certain transformation to make them sane for just pulling
into the relevant target repositories.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-11 13:18                                                 ` David Woodhouse
@ 2013-02-11 13:58                                                   ` Anca Emanuel
  2013-02-11 16:34                                                   ` Linus Torvalds
  2013-02-11 17:41                                                   ` Ingo Molnar
  2 siblings, 0 replies; 65+ messages in thread
From: Anca Emanuel @ 2013-02-11 13:58 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Ingo Molnar, Linus Torvalds, Pekka Enberg,
	Linux Kernel Mailing List, H. Peter Anvin, Randy Dunlap,
	Thomas Gleixner, David Rientjes, Greg Kroah-Hartman, Sasha Levin,
	H. Peter Anvin, Michal Marek, Stephen Rothwell

[quote]the ultimate goal being to make this new socket family
hypervisor-neutral[/quote]
That was from vmware.
If somebody will make something generic, to please xen, kvm, vmware,
and others in an 15 to 20 years time...
Then a tool like this will be accepted ?

Linus, you know this tool was only for x86.
Now if you look at this:
https://github.com/penberg/linux-kvm/commit/051bdb63879385e12b7e253b72cdde909a5e0b9b
There are other platforms added.
Look here: https://wiki.linaro.org/LEG/Engineering/Virtualization
[quote]kvmtool is used meanwhile[/quote]
They are using it !


On Mon, Feb 11, 2013 at 3:18 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Mon, 2013-02-11 at 13:56 +0100, Ingo Molnar wrote:
>> To use another, perhaps more applicable analogy:
>>
>> If one has the choice to start a new business in the U.S., it
>> would be reasonable to do that. There's a lot of supporting
>> infrastructure, trust, distribution, standards, enforcement
>> agencies and available workers.
>>
>> Could the same business succeed in Somalia as well? Possibly -
>> if it's a bakery or something similarly fundamental. More
>> complex businesses would likely not thrive very well there.
>>
>> *That* is how I think the current Linux kernel tooling landscape
>> looks like currently in a fair number of places: in many aspects
>> it's similar to Somalia - disjunct entities with not much
>> commonality or shared infrastructure.
>
> That's complete nonsense. If you want to use pieces of the kernel
> infrastructure, then just *take* them. There are loads of projects which
> use the kernel config tools, for example. There's no need to be *in* the
> kernel repo.
>
> And for code-reuse it's even easy enough to automatically extract parts
> of kernel code into a separate repository. See the ecos-jffs2 and
> linux-headers trees, for example, which automatically tracked Linus'
> tree with a certain transformation to make them sane for just pulling
> into the relevant target repositories.
>
> --
> dwmw2
>

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-11 12:26                                             ` Ingo Molnar
  2013-02-11 12:56                                               ` Ingo Molnar
@ 2013-02-11 14:47                                               ` Pekka Enberg
  2013-02-11 16:46                                                 ` David Woodhouse
  2013-02-11 16:32                                               ` Linus Torvalds
  2 siblings, 1 reply; 65+ messages in thread
From: Pekka Enberg @ 2013-02-11 14:47 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, Linux Kernel Mailing List, H. Peter Anvin,
	Randy Dunlap, Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell

On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar <mingo@kernel.org> wrote:
> IIRC Windows support for kmvtool is work in progress - some
> patches already got applied.

People are working on SeaBIOS support which is just one part of
running Windows. But yeah, we'll hopefully support non-Linux guest at
some point.

On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar <mingo@kernel.org> wrote:
>> What if somebody tells you that they are really tired of Xen,
>> and actually want to turn kvmtool into *replacement* for Xen
>> instead? [...]
>
> Actually, this was raised by some people - and I think some
> generalization patches were applied already but Pekka might know
> more about that ...

There was some interest but I don't think anybody sent patches for
that. There's no fundamental reason why we couldn't support Xen if
people are interested in working on that.

                        Pekka

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-11 12:26                                             ` Ingo Molnar
  2013-02-11 12:56                                               ` Ingo Molnar
  2013-02-11 14:47                                               ` Pekka Enberg
@ 2013-02-11 16:32                                               ` Linus Torvalds
  2013-02-11 17:28                                                 ` Ingo Molnar
  2 siblings, 1 reply; 65+ messages in thread
From: Linus Torvalds @ 2013-02-11 16:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Pekka Enberg, Linux Kernel Mailing List, H. Peter Anvin,
	Randy Dunlap, Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell

On Mon, Feb 11, 2013 at 4:26 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> If you are asking whether it is critical for the kernel project
> to have tools/kvm/ integrated then it isn't. The kernel will
> live just fine without it, even if that decision is a mistake.

You go on to explain how this helps kvmtool, and quite frankly, I DO NOT CARE.

Everything you talk about is about helping your work, by making the
kernel maintenance be more. The fact that you want to use kernel
infrastructure in kvmtool is a great example: you may think it's a
great thing, but for the kernel it's just extra work, and extra layers
of abstraction etc etc.

And then you make it clear that you haven't even *bothered* to try to
make it a separate project.

Sorry, but with that kind of approach, I get less and less interested.
I think this whole tying together is a big mistake. It encourages
linkages that simply shouldn't be there.

And no, perf is not the perfect counter-example. With perf,. the
linkages made sense! There's supposed to be deep linkages to profiling
and event counting. There is ABSOLUTELY NOT supposed to be deep
linkages with virtualization. Quite the reverse.

And no, I don't want to maintain the mess that is both. There's just
no gain, and lots of potential pain.

                    Linus

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-11 13:18                                                 ` David Woodhouse
  2013-02-11 13:58                                                   ` Anca Emanuel
@ 2013-02-11 16:34                                                   ` Linus Torvalds
  2013-02-11 17:34                                                     ` H. Peter Anvin
  2013-02-11 17:41                                                   ` Ingo Molnar
  2 siblings, 1 reply; 65+ messages in thread
From: Linus Torvalds @ 2013-02-11 16:34 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Ingo Molnar, Pekka Enberg, Linux Kernel Mailing List,
	H. Peter Anvin, Randy Dunlap, Thomas Gleixner, David Rientjes,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell

On Mon, Feb 11, 2013 at 5:18 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>
> That's complete nonsense. If you want to use pieces of the kernel
> infrastructure, then just *take* them. There are loads of projects which
> use the kernel config tools, for example. There's no need to be *in* the
> kernel repo.

Exactly. I do *not* want a abstraction layer just because somebody
wants to use it. It causes idiotic guards in the header files etc. We
already had that pain with the user-level header inclusions etc.

Just copy it.

            Linus

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-11 14:47                                               ` Pekka Enberg
@ 2013-02-11 16:46                                                 ` David Woodhouse
  2013-02-11 17:26                                                   ` Anca Emanuel
  0 siblings, 1 reply; 65+ messages in thread
From: David Woodhouse @ 2013-02-11 16:46 UTC (permalink / raw)
  To: Pekka Enberg
  Cc: Ingo Molnar, Linus Torvalds, Linux Kernel Mailing List,
	H. Peter Anvin, Randy Dunlap, Thomas Gleixner, David Rientjes,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

On Mon, 2013-02-11 at 16:47 +0200, Pekka Enberg wrote:
> On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar <mingo@kernel.org> wrote:
> > IIRC Windows support for kmvtool is work in progress - some
> > patches already got applied.
> 
> People are working on SeaBIOS support which is just one part of
> running Windows. But yeah, we'll hopefully support non-Linux guest at
> some point. 

<digression>

You're probably better off focusing on OVMF rather than just SeaBIOS.

SeaBIOS has CSM support now, so it can provide 'legacy' BIOS services
under OVMF. So if OVMF runs, you get both EFI and legacy support.

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-11 16:46                                                 ` David Woodhouse
@ 2013-02-11 17:26                                                   ` Anca Emanuel
  0 siblings, 0 replies; 65+ messages in thread
From: Anca Emanuel @ 2013-02-11 17:26 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Pekka Enberg, Ingo Molnar, Linus Torvalds,
	Linux Kernel Mailing List, H. Peter Anvin, Randy Dunlap,
	Thomas Gleixner, David Rientjes, Greg Kroah-Hartman, Sasha Levin,
	H. Peter Anvin, Michal Marek, Stephen Rothwell

Linus, will you help to the project ?
Talk to Linaro guys.

On Mon, Feb 11, 2013 at 6:46 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Mon, 2013-02-11 at 16:47 +0200, Pekka Enberg wrote:
>> On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar <mingo@kernel.org> wrote:
>> > IIRC Windows support for kmvtool is work in progress - some
>> > patches already got applied.
>>
>> People are working on SeaBIOS support which is just one part of
>> running Windows. But yeah, we'll hopefully support non-Linux guest at
>> some point.
>
> <digression>
>
> You're probably better off focusing on OVMF rather than just SeaBIOS.
>
> SeaBIOS has CSM support now, so it can provide 'legacy' BIOS services
> under OVMF. So if OVMF runs, you get both EFI and legacy support.
>
> --
> dwmw2

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-11 16:32                                               ` Linus Torvalds
@ 2013-02-11 17:28                                                 ` Ingo Molnar
       [not found]                                                   ` <CA+55aFx-0-qcYMqH2wnJJ7iAPhoEvD_EQ0xqVW3VGS3G9=_1_w@mail.gmail.com>
  0 siblings, 1 reply; 65+ messages in thread
From: Ingo Molnar @ 2013-02-11 17:28 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Pekka Enberg, Linux Kernel Mailing List, H. Peter Anvin,
	Randy Dunlap, Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Feb 11, 2013 at 4:26 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > If you are asking whether it is critical for the kernel 
> > project to have tools/kvm/ integrated then it isn't. The 
> > kernel will live just fine without it, even if that decision 
> > is a mistake.
> 
> You go on to explain how this helps kvmtool, and quite 
> frankly, I DO NOT CARE.

Me and Pekka also listed several examples of how it already 
helped the kernel, despite it only being partially present in 
some kernel repos:

 - Pekka listed new virtio drivers that were done via tools/kvm.

 - Pekka listed ARM KVM support which was written/prototyped
   using tools/kvm.

 - There's over a dozen bugfixes in your kernel which were found 
   via syscall fuzzing built into tools/kvm. (I can dig them all
   out if you want.)

 - There are several fixes in the kernel side KVM subsystem
   itself that were unearthed via tools/kvm.

 - I showed how it helped the kernel by creating user-space
   lockdep: code used in more situations means more exposure,
   more bugfixes and more contributors. (It also allowed
   immediate lockdep coverage for all the user-space mutexes
   that tools/perf/ itself uses.)

Those were all real benefits to the kernel which are upstream or 
almost upstream today.

This tool alone generated a *more* versatile number of 
improvements to the kernel than the majority of filesystems and 
the majority of drivers in the Linux kernel tree today has ever 
achieved.

How on earth can anyone, against all that evidence, still claim 
that it's a net minus?

> Everything you talk about is about helping your work, by 
> making the kernel maintenance be more. The fact that you want 
> to use kernel infrastructure in kvmtool is a great example: 
> you may think it's a great thing, but for the kernel it's just 
> extra work, and extra layers of abstraction etc etc.

At least in the case of lockdep, the kernel side change enabling 
it was a trivial:

  kernel/lockdep.c | 4 ++++
  1 file changed, 4 insertions(+)

... but we could probably make even that interaction go away and 
make it exactly zero, and push all the changes on to the 
liblockdep side.

Anyway, should I consider user space lockdep NAK-ed too in this 
form, before we put any more work into it?

> And then you make it clear that you haven't even *bothered* to 
> try to make it a separate project.

Just like back in the days you haven't even bothered to make 
Linux a proper GNU project, and for good reasons. Nor have I 
ever tried to write scheduler code for another OS.

Some expensive, disruptive things you don't "try" because you 
disagree with the model, on what you think to be valid grounds. 
You make a judgement call, you take your chances, and you see 
whether it works.

> Sorry, but with that kind of approach, I get less and less 
> interested. I think this whole tying together is a big 
> mistake. It encourages linkages that simply shouldn't be 
> there.
> 
> And no, perf is not the perfect counter-example. With perf,. 
> the linkages made sense! There's supposed to be deep linkages 
> to profiling and event counting. There is ABSOLUTELY NOT 
> supposed to be deep linkages with virtualization. Quite the 
> reverse.

I'm *really* surprised that you say that.

perf interfaces to the Linux kernel in a very similar way to how 
tools/kvm interfaces to the Linux kernel: both use (very) Linux 
specific system calls to run on a host system running the Linux 
kernel.

Neither tool will in the foreseeable future execute on any 
other, non-Linux host kernel.

( Running non-Linux guest OS's is an entirely different matter
  and there's no fundamental restriction there. )

tools/perf/ is not in the kernel because it interfaces with the 
kernel in nasty, incestous ways.

It is in the kernel mainly because that's the contribution model 
that turned out to work well for both the kernel and the tooling 
side:

I initially made the user-space bits of perf a separate project. 
I didn't run it in that form for a long time, but I got 
essentially zero contributions. The moment it went into a silly 
directory in Documentation/perf_counters/, contributions started 
trickling in. Today it's fully embraced by the kernel side 
subsystem and allows very efficient interface enhancements on 
the kernel and tooling side, in lock-step - benefiting both 
sides significantly.

> And no, I don't want to maintain the mess that is both. 
> There's just no gain, and lots of potential pain.

I disagree, and I don't see the validity of most of your 
arguments, but it's obviously your call.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-11 16:34                                                   ` Linus Torvalds
@ 2013-02-11 17:34                                                     ` H. Peter Anvin
  0 siblings, 0 replies; 65+ messages in thread
From: H. Peter Anvin @ 2013-02-11 17:34 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: David Woodhouse, Ingo Molnar, Pekka Enberg,
	Linux Kernel Mailing List, H. Peter Anvin, Randy Dunlap,
	Thomas Gleixner, David Rientjes, Greg Kroah-Hartman, Sasha Levin,
	Michal Marek, Stephen Rothwell

On 02/11/2013 08:34 AM, Linus Torvalds wrote:
> On Mon, Feb 11, 2013 at 5:18 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>>
>> That's complete nonsense. If you want to use pieces of the kernel
>> infrastructure, then just *take* them. There are loads of projects which
>> use the kernel config tools, for example. There's no need to be *in* the
>> kernel repo.
>
> Exactly. I do *not* want a abstraction layer just because somebody
> wants to use it. It causes idiotic guards in the header files etc. We
> already had that pain with the user-level header inclusions etc.
>
> Just copy it.
>

The UAPI work and "make headers_install" already has cleaned things up 
immensely.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-11 13:18                                                 ` David Woodhouse
  2013-02-11 13:58                                                   ` Anca Emanuel
  2013-02-11 16:34                                                   ` Linus Torvalds
@ 2013-02-11 17:41                                                   ` Ingo Molnar
  2 siblings, 0 replies; 65+ messages in thread
From: Ingo Molnar @ 2013-02-11 17:41 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Linus Torvalds, Pekka Enberg, Linux Kernel Mailing List,
	H. Peter Anvin, Randy Dunlap, Thomas Gleixner, David Rientjes,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Michal Marek,
	Stephen Rothwell


* David Woodhouse <dwmw2@infradead.org> wrote:

> On Mon, 2013-02-11 at 13:56 +0100, Ingo Molnar wrote:
> > To use another, perhaps more applicable analogy:
> > 
> > If one has the choice to start a new business in the U.S., it 
> > would be reasonable to do that. There's a lot of supporting 
> > infrastructure, trust, distribution, standards, enforcement 
> > agencies and available workers.
> > 
> > Could the same business succeed in Somalia as well? Possibly - 
> > if it's a bakery or something similarly fundamental. More 
> > complex businesses would likely not thrive very well there.
> > 
> > *That* is how I think the current Linux kernel tooling landscape 
> > looks like currently in a fair number of places: in many aspects 
> > it's similar to Somalia - disjunct entities with not much 
> > commonality or shared infrastructure.
> 
> That's complete nonsense. If you want to use pieces of the 
> kernel infrastructure, then just *take* them. [...]

So I can take the mailing lists and the whole contribution 
culture? Hardly...

I was not talking about code alone, I was also talking about a 
social environment - which is not a one sided relationship at 
all, it improves the kernel code, like it already did for over 
two dozen tools/kvm originated patches:

To quote from my mail to Linus:

"
 - Pekka listed new virtio drivers that were done via tools/kvm.

 - Pekka listed ARM KVM support which was written/prototyped
   using tools/kvm.

 - There's over a dozen bugfixes in your kernel which were found
   via syscall fuzzing built into tools/kvm. (I can dig them all
   out if you want.)

 - There are several fixes in the kernel side KVM subsystem
   itself that were unearthed via tools/kvm.

 - I showed how it helped the kernel by creating user-space
   lockdep: code used in more situations means more exposure,
   more bugfixes and more contributors. (It also allowed
   immediate lockdep coverage for all the user-space mutexes
   that tools/perf/ itself uses.)

Those were all real benefits to the kernel which are upstream or
almost upstream today.

This tool alone generated a *more* versatile number of
improvements to the kernel than the majority of filesystems and
the majority of drivers in the Linux kernel tree today has ever
achieved. "

> [...] There are loads of projects which use the kernel config 
> tools, for example. There's no need to be *in* the kernel 
> repo.
> 
> And for code-reuse it's even easy enough to automatically 
> extract parts of kernel code into a separate repository. [...]

... which solution would:

 - lose all history
 - lose contributor awareness of each other
 - lose easy cross-contribution pathways

That's a severe net minus in my opinion.

I think you should try to answer the very fundamental 
observation I made and the question I asked in my mail to Tytso:

"
We have first hand experience there: tools/perf/.

None of the predicted extreme badness happened. Yes, sometimes 
we broke compatibility as ABI changes/enhancements do - but 
treated them as regressions and fixed them. I also think that 
considering the rate of changes our breakage ratio is very good.

So no badness happened, and in fact a lot of goodness happened: 
which goodness never happened while Linux profiling was a 
separate project isolated as a user-space utility!

Anyone opposing integration I think *HAS* to explain the 
mechanics behind this very example in plain sight.

Why the heck has pretty much every other out of tree profiling 
project died, while the in-tree one is thriving?

Yes, the key is that Arnaldo is good, and so are the other perf 
contributors - and they are good because they feel at home and 
they are productive. Being in the kernel repo is actually 90% 
responsible for that environment!
"

And yes, based on the evidence I think much of perf's current 
vitality would be killed off or would be severely reduced if it 
was forced into a separate, out of tree project.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
       [not found]                                                   ` <CA+55aFx-0-qcYMqH2wnJJ7iAPhoEvD_EQ0xqVW3VGS3G9=_1_w@mail.gmail.com>
@ 2013-02-11 17:58                                                     ` Ingo Molnar
  2013-02-11 23:32                                                       ` Linus Torvalds
  0 siblings, 1 reply; 65+ messages in thread
From: Ingo Molnar @ 2013-02-11 17:58 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: H. Peter Anvin, Linux Kernel Mailing List, Randy Dunlap,
	Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Pekka Enberg,
	Michal Marek, Stephen Rothwell


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Feb 11, 2013 9:28 AM, "Ingo Molnar" <mingo@kernel.org> wrote:
>
> > How on earth can anyone, against all that evidence, still 
> > claim that it's a net minus?
> 
> Because I don't think there is any reason for mixing up the 
> projects. Why do you not just make it separate? Everything you 
> claim is such a big deal would still work perfectly well.
> 
> Every time you talk about "negative" it's as of the project 
> wouldn't exist if it was external. Which is total bull, since 
> it is effectively external already. [...]

That's not actually true. If you check the list of early 
tools/kvm/ contributors you will see an overlap with -tip 
contributors. I know tools/kvm/ developers who just use their 
existing -tip repo to pick up the latest. They are using the 
-tip commit notifications to see what went in and what not, etc.

Claiming that because the contribution model works to a certain 
degree integrated into a small Linux subsystem tree it does not 
ever have to go upstream is so wrong on so many levels ...

The most likely correct statement would be something like: "if 
it worked on a small scale it will probably work even better 
with more exposure on a larger scale." We'll never know that 
though.

( That is also why some of the focus was on lockdep - knowing 
  that it's close in terms of maintenance distance made it an 
  easier topic - socially. )

Since I'm using it on an almost daily basis to test out failed 
bzImages, and because I (mistakenly) thought it had some 
upstream chances, I found it good to help out (a bit) with 
maintenance and code review.

While it works it's obviously limited - there's just so many 
-tip developers and I thought everyone would benefit from this 
going the next natural step.

> [...] And it will stay that way. You are just in denial and 
> trying to say that integrating it would somehow help.
> 
> And I claim it wouldn't. It works fine outside already. Just 
> ADMIT it.

So tools/kvm/ works 'just fine' - in its current limited form - 
because for the developers involved it's already "upstream", for 
the first hop of upstream.

So basically Pekka optimistically thought it's an eventual 'tit 
for tat', a constant stream of benefits to the kernel, in the 
hope of finding a home in the upstream kernel which would 
further help both projects. The kernel wants to keep the 'tit' 
only though.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-11 17:58                                                     ` Ingo Molnar
@ 2013-02-11 23:32                                                       ` Linus Torvalds
  2013-02-12  9:52                                                         ` Ingo Molnar
  0 siblings, 1 reply; 65+ messages in thread
From: Linus Torvalds @ 2013-02-11 23:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: H. Peter Anvin, Linux Kernel Mailing List, Randy Dunlap,
	Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Pekka Enberg,
	Michal Marek, Stephen Rothwell

On Mon, Feb 11, 2013 at 9:58 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> So basically Pekka optimistically thought it's an eventual 'tit
> for tat', a constant stream of benefits to the kernel, in the
> hope of finding a home in the upstream kernel which would
> further help both projects. The kernel wants to keep the 'tit'
> only though.

Ingo, stop this idiotic nonsense.

You seem to think that "kvmtool is useful for kernel" is somehow relevant.

IT IS TOTALLY IRRELEVANT.

"sparse" is useful for kernel development. "git" is useful for kernel
development. "xterm" is useful for kernel development.

See a pattern? We have tons of tools that are helping develop the
kernel, and for absolutely NONE of them is that at all an argument for
merging them into the kernel.

If the Xen people came and asked me to merge their virtualizer code
into the kernel, I'd call them idiots.

Why is kvmtool so magical that you use this argument for merging it
into the kernel?

It makes no sense.

Yet you continue to use it as if it was somehow an argument for
merging it. Despite the hundreds of projects to the contrary.

So this whole "constant stream of benefits" you talk about is PURE AND
UTTER GARBAGE. And that's not a commentary on whether it is true or
not, it's a commentary on the fact that it is entirely irrelevant to
whether something should be merged.

Merging two projects does not make them easier to maintain. Quite the
reverse. It just ties the maintenance together in irrelevant ways.

                       Linus

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-11 23:32                                                       ` Linus Torvalds
@ 2013-02-12  9:52                                                         ` Ingo Molnar
  2013-02-13  8:23                                                           ` Paolo Bonzini
  0 siblings, 1 reply; 65+ messages in thread
From: Ingo Molnar @ 2013-02-12  9:52 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: H. Peter Anvin, Linux Kernel Mailing List, Randy Dunlap,
	Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Pekka Enberg,
	Michal Marek, Stephen Rothwell


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Feb 11, 2013 at 9:58 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > So basically Pekka optimistically thought it's an eventual 
> > 'tit for tat', a constant stream of benefits to the kernel, 
> > in the hope of finding a home in the upstream kernel which 
> > would further help both projects. The kernel wants to keep 
> > the 'tit' only though.
> 
> Ingo, stop this idiotic nonsense.
> 
> You seem to think that "kvmtool is useful for kernel" is 
> somehow relevant.
> 
> IT IS TOTALLY IRRELEVANT.

Please stop misrepresenting my opinion. My argument continues to 
be that it was useful to the kernel in significant part 
*BECAUSE* tools/kvm/ was integrated into a kernel repository - 
on the main developers' systems.

You seem to take it for granted that causality cannot possibly 
go the way that these kernel enhancements came mainly because 
the tool was integrated into a kernel repo and was developed 
very consciously within a kernel repo, as a (foster-)sister 
project.

Why are you making that assumption? It's totally debatable and 
we, who experienced that development process first hand, are 
fiercely debating it.

Check the list I gave (unmodified):

"- Pekka listed new virtio drivers that were done via tools/kvm. 

 - Pekka listed ARM KVM support which was written/prototyped
   using tools/kvm.

 - There's over a dozen bugfixes in your kernel which were found
   via syscall fuzzing built into tools/kvm. (I can dig them all
   out if you want.)

 - There are several fixes in the kernel side KVM subsystem
   itself that were unearthed via tools/kvm.

 - I showed how it helped the kernel by creating user-space
   lockdep: code used in more situations means more exposure,
   more bugfixes and more contributors. (It also allowed
   immediate lockdep coverage for all the user-space mutexes
   that tools/perf/ itself uses.)"

All but the fourth item (KVM fixes) were benefits that arose 
largely because the tool was integrated into a kernel repository 
and the developers found it easy to work that way.

In at least 3 cases above I could describe the actual, specific 
development process that involved a single code base, even 
adding features to *BOTH* the tool and the kernel, in one work 
flow.

The resulting patches were then rebased after the fact (mostly 
by Pekka), to merge upstream separately while waiting for the 
tool to prove itself for upstream - losing its origin, 
motivation and its history.

Could it have been attempted separately? Yes, just like perf 
could have been tried as a separate project - but that is not 
how it happened, that is not how the development flow unfolded, 
and that is not what motivated those enhancements.

Just because it _could_ have been done independently does not 
change the plain fact that tools/kvm was immensely kernel 
focused.

Yes, it was unsolicited, yes you objected early on and loud 
enough, and the kernel did not ask for this integration to begin 
with - so there's not a hint of obligation on your part 
whatsoever, but that does not change development reality as it 
happened. I refuse to accept the rewriting of history.

> "sparse" is useful for kernel development. "git" is useful for 
> kernel development. "xterm" is useful for kernel development.

That argument is silly beyond belief. Read this list:

  - tools/kvm
  - sparse
  - git
  - xterm
  - perf

Which two tools in this list:

 - Use and focus on Linux specific system calls to provide Linux
   specific functionality?

 - Are never - and will conceivably never - run on any kernel
   which is not extremely Linux compatible?

 - Provide essential features that need serious, tool specific
   kernel side support?

 - Were used directly to create integrated features that add 
   features BOTH to the kernel and the tool, at once?

I know that this discussion is not about changing your mind 
anymore - every further email probably does the opposite.
I would accept many other arguments from you:

 - you feel uneasy about growing the kernel into any sort of 
   platform. I would disagree but it's a fair argument.

 - you think kernel developers should not do user-space 
   development and there should be a 'chinese wall' of ignorance
   and a project boundary or two between them. I would disagree 
   but it's a fair argument.

 - you think Qemu is better and is the official kernel side KVM 
   tool, and even if it's not better, it's (much) more complete 
   and a schizm is bad. It's a fair argument that I'd somewhat 
   agree with.

 - you feel that if a tool cannot survive in the harsh realities 
   of the sourceforge or github ghetto, succeeding in 
   establishing itself and then hurting generations of
   users with inconsistent, uncoordinated tinkerware, no matter 
   how Linux kernel centric the tool is conceptually, then it
   does not deserve to live at all. I would disagree but it
   would be a fair argument.

 - you feel the kernel should be fundamentally tool neutral, 
   even if the lack of coherence and elongated coordination is
   hurting the kernel, tools, developers and users. I'd disagree
   with that but it would be a fair argument.

but stop the "integration did not benefit the kernel" or 
"integration did not benefit the tool" crap please, it's 
insulting. Both claims are false even if you ignore the 
tools/perf example that shows the possible.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-12  9:52                                                         ` Ingo Molnar
@ 2013-02-13  8:23                                                           ` Paolo Bonzini
  2013-02-13  8:56                                                             ` Pekka Enberg
  0 siblings, 1 reply; 65+ messages in thread
From: Paolo Bonzini @ 2013-02-13  8:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Linus Torvalds, H. Peter Anvin, Linux Kernel Mailing List,
	Randy Dunlap, Thomas Gleixner, David Rientjes, David Woodhouse,
	Greg Kroah-Hartman, Sasha Levin, H. Peter Anvin, Pekka Enberg,
	Michal Marek, Stephen Rothwell

Il 12/02/2013 10:52, Ingo Molnar ha scritto:
> Check the list I gave (unmodified):
> 
> "- Pekka listed new virtio drivers that were done via tools/kvm. 

vhost-scsi got in first in tools/kvm, but out-of-tree patches had
existed for QEMU for more than a year.  It was developed with QEMU.

>  - Pekka listed ARM KVM support which was written/prototyped
>    using tools/kvm.

Again, I think both QEMU and tools/kvm were used, with QEMU probably
coming first.  However, I'm not 100% sure.

>  - There's over a dozen bugfixes in your kernel which were found
>    via syscall fuzzing built into tools/kvm. (I can dig them all
>    out if you want.)

This sounds like something that runs in a guest, not in the host.  As
such it need not be tied to tools/kvm.  If there is a host component
(host C code), I'd be interested.  I know that Fujitsu guys have patches
for panic notification from the guest kernel, for example.

But if there is a host component to it, then please go back to the
original purpose of tools/kvm.  Drop all the QCOW, VNC, SeaBIOS
nonsense.  Drop the userspace networking stack (tap is enough).  Make
the tool into a library that supports nothing but virtio-{blk,net,9p}
and VFIO.  Build _many_ narrow-focused tools around that library.

>> "sparse" is useful for kernel development. "git" is useful for 
>> kernel development. "xterm" is useful for kernel development.
> 
> That argument is silly beyond belief. Read this list:
> 
>   - tools/kvm
>   - sparse
>   - git
>   - xterm
>   - perf
> 
> Which two tools in this list:
> 
>  - Use and focus on Linux specific system calls to provide Linux
>    specific functionality?
> 
>  - Are never - and will conceivably never - run on any kernel
>    which is not extremely Linux compatible?

QEMU runs KVM on Solaris, FWIW.

Paolo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-13  8:23                                                           ` Paolo Bonzini
@ 2013-02-13  8:56                                                             ` Pekka Enberg
  2013-02-13  9:23                                                               ` Ingo Molnar
  2013-02-14 15:32                                                               ` Anthony Liguori
  0 siblings, 2 replies; 65+ messages in thread
From: Pekka Enberg @ 2013-02-13  8:56 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Ingo Molnar, Linus Torvalds, H. Peter Anvin,
	Linux Kernel Mailing List, Randy Dunlap, Thomas Gleixner,
	David Rientjes, David Woodhouse, Greg Kroah-Hartman, Sasha Levin,
	H. Peter Anvin, Michal Marek, Stephen Rothwell

On Wed, Feb 13, 2013 at 10:23 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 12/02/2013 10:52, Ingo Molnar ha scritto:
>> Check the list I gave (unmodified):
>>
>> "- Pekka listed new virtio drivers that were done via tools/kvm.
>
> vhost-scsi got in first in tools/kvm, but out-of-tree patches had
> existed for QEMU for more than a year.  It was developed with QEMU.

I think Ingo confused virtio and vhost. IIRC, Asias developed
vhost-blk using tools/kvm.

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-13  8:56                                                             ` Pekka Enberg
@ 2013-02-13  9:23                                                               ` Ingo Molnar
  2013-02-14 15:32                                                               ` Anthony Liguori
  1 sibling, 0 replies; 65+ messages in thread
From: Ingo Molnar @ 2013-02-13  9:23 UTC (permalink / raw)
  To: Pekka Enberg
  Cc: Paolo Bonzini, Linus Torvalds, H. Peter Anvin,
	Linux Kernel Mailing List, Randy Dunlap, Thomas Gleixner,
	David Rientjes, David Woodhouse, Greg Kroah-Hartman, Sasha Levin,
	H. Peter Anvin, Michal Marek, Stephen Rothwell


* Pekka Enberg <penberg@kernel.org> wrote:

> I think Ingo confused virtio and vhost. IIRC, Asias developed 
> vhost-blk using tools/kvm.

Erm, indeed - sorry.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-13  8:56                                                             ` Pekka Enberg
  2013-02-13  9:23                                                               ` Ingo Molnar
@ 2013-02-14 15:32                                                               ` Anthony Liguori
  1 sibling, 0 replies; 65+ messages in thread
From: Anthony Liguori @ 2013-02-14 15:32 UTC (permalink / raw)
  To: Pekka Enberg
  Cc: Paolo Bonzini, Ingo Molnar, Linus Torvalds, H. Peter Anvin,
	Linux Kernel Mailing List, Randy Dunlap, Thomas Gleixner,
	David Rientjes, David Woodhouse, Greg Kroah-Hartman, Sasha Levin,
	H. Peter Anvin, Michal Marek, Stephen Rothwell

On 02/13/2013 02:56 AM, Pekka Enberg wrote:
> On Wed, Feb 13, 2013 at 10:23 AM, Paolo Bonzini<pbonzini@redhat.com>  wrote:
>> Il 12/02/2013 10:52, Ingo Molnar ha scritto:
>>> Check the list I gave (unmodified):
>>>
>>> "- Pekka listed new virtio drivers that were done via tools/kvm.
>>
>> vhost-scsi got in first in tools/kvm, but out-of-tree patches had
>> existed for QEMU for more than a year.  It was developed with QEMU.
>
> I think Ingo confused virtio and vhost. IIRC, Asias developed
> vhost-blk using tools/kvm.

We've done extensive performance analysis of vhost-blk and it's not any faster 
than a userspace solution.  This is why it's still not in mainline.

This wasn't noticed with tools/kvm because it's block layer is too simplistic.

In order to get to the point where we're able to do this well in userspace in 
QEMU took tons of bug fixes to the kernel and added features (like 
pread64/pwrite64).

That all happened without QEMU being in the kernel.

Regards,

Anthony Liguori



^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: kvmtool tree (Was: Re: [patch] config: fix make kvmconfig)
  2013-02-08 14:55                             ` Ingo Molnar
  2013-02-08 21:14                               ` Linus Torvalds
@ 2013-02-19  8:08                               ` Ingo Molnar
  1 sibling, 0 replies; 65+ messages in thread
From: Ingo Molnar @ 2013-02-19  8:08 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Rientjes, Pekka Enberg, Linus Torvalds, Greg Kroah-Hartman,
	Sasha Levin, Randy Dunlap, David Woodhouse, Michal Marek,
	H. Peter Anvin, tglx, H. Peter Anvin, linux-kernel


* Ingo Molnar <mingo@kernel.org> wrote:

> I'll remove it if Linus insists on it, but I think you guys 
> are putting form before substance and utility :-(

So, just to bring this to a conclusion, obviously Linus is 
insisting on it, so I've removed tools/kvm from tip:auto-latest, 
by going back from the daily merges (where tip:master was == 
tip:next) to the older complete reintegration merges to 
linux-next every couple of weeks.

This way tools/kvm will still be available in tip:master (merged 
after full integrations) and there are still the usual daily (or 
more frequent) delta-merges of tip:master as new bits get ready 
- with the occasional riskier total reintegration done for 
linux-next.

It's obviously not optimal, but that's the best I could come up 
with given the constraints.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH] x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT
  2012-12-20 21:51 [PATCH] x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT David Woodhouse
  2012-12-21  2:07 ` [tip:x86/build] x86: Default to ARCH= x86 " tip-bot for David Woodhouse
@ 2013-04-12 16:01 ` richard -rw- weinberger
  2013-04-12 16:38   ` David Woodhouse
  1 sibling, 1 reply; 65+ messages in thread
From: richard -rw- weinberger @ 2013-04-12 16:01 UTC (permalink / raw)
  To: David Woodhouse; +Cc: x86, LKML

David,

On Thu, Dec 20, 2012 at 10:51 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> -SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
> +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
> +                                 -e s/sun4u/sparc64/ \
>                                   -e s/arm.*/arm/ -e s/sa110/arm/ \
>                                   -e s/s390x/s390/ -e s/parisc64/parisc/ \
>                                   -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \

Why is this change needed? Especially the -e s/x86_64/x86.
It causes UML to get build for x86 which is a nasty change
of the default behavior.

Before your change you got a UML kernel for the underlying arch just
by running "make linux ARCH=um".
Now it will always build a x86 UML kernel, also if you run it on
x86_64 and one is forced to override
SUBARCH by hand.

--
Thanks,
//richard

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH] x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT
  2013-04-12 16:01 ` [PATCH] x86: Default to ARCH=x86 " richard -rw- weinberger
@ 2013-04-12 16:38   ` David Woodhouse
  0 siblings, 0 replies; 65+ messages in thread
From: David Woodhouse @ 2013-04-12 16:38 UTC (permalink / raw)
  To: richard -rw- weinberger; +Cc: x86, LKML

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

On Fri, 2013-04-12 at 18:01 +0200, richard -rw- weinberger wrote:
> David,
> 
> On Thu, Dec 20, 2012 at 10:51 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> > -SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
> > +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
> > +                                 -e s/sun4u/sparc64/ \
> >                                   -e s/arm.*/arm/ -e s/sa110/arm/ \
> >                                   -e s/s390x/s390/ -e s/parisc64/parisc/ \
> >                                   -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
> 
> Why is this change needed? Especially the -e s/x86_64/x86.
> It causes UML to get build for x86 which is a nasty change
> of the default behavior.

Which one? The "new" change of {i.86,x86_64} -> x86, or the pre-existing
ones for s390, parisc, powerpc and mips that it's falling into line
with?

> Before your change you got a UML kernel for the underlying arch just
> by running "make linux ARCH=um".
> Now it will always build a x86 UML kernel, also if you run it on
> x86_64 and one is forced to override
> SUBARCH by hand.

I know this was true a number of years ago when I first submitted this
fix. But I thought the ARCH=x86 UML build had been fixed since then. And
I was fairly sure I'd *tested* that belief when recently resubmitting...

Isn't it merely a case of setting CONFIG_64BIT to the desired value?

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

^ permalink raw reply	[flat|nested] 65+ messages in thread

end of thread, other threads:[~2013-04-12 16:38 UTC | newest]

Thread overview: 65+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-20 21:51 [PATCH] x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT David Woodhouse
2012-12-21  2:07 ` [tip:x86/build] x86: Default to ARCH= x86 " tip-bot for David Woodhouse
2012-12-26  6:32   ` David Rientjes
2012-12-26  8:43     ` David Woodhouse
2012-12-26 10:44       ` David Rientjes
2012-12-26 12:38         ` David Woodhouse
2012-12-26 22:00           ` David Rientjes
2012-12-26 22:19             ` David Woodhouse
2012-12-27  1:52               ` David Rientjes
2012-12-27  8:01                 ` David Woodhouse
2012-12-26 22:30             ` Jesper Juhl
2012-12-26 23:07             ` David Woodhouse
2012-12-26 23:13             ` H. Peter Anvin
2012-12-26 23:32     ` [tip] config: Add 'make kvmconfig' David Woodhouse
2012-12-27  1:08       ` Randy Dunlap
2013-02-04 18:20         ` [patch] config: fix make kvmconfig David Rientjes
2013-02-04 18:44           ` Ingo Molnar
2013-02-04 18:57             ` David Rientjes
2013-02-04 19:11               ` Ingo Molnar
2013-02-04 19:14               ` Greg Kroah-Hartman
2013-02-04 19:13                 ` Ingo Molnar
2013-02-06 18:25                   ` Pekka Enberg
2013-02-06 20:12                     ` David Rientjes
2013-02-06 20:45                       ` Pekka Enberg
2013-02-06 21:02                       ` kvmtool tree (Was: Re: [patch] config: fix make kvmconfig) Stephen Rothwell
2013-02-06 21:46                         ` Ingo Molnar
2013-02-06 21:55                           ` H. Peter Anvin
2013-02-07 21:44                             ` Stephen Rothwell
2013-02-07 21:40                           ` Stephen Rothwell
2013-02-08 14:55                             ` Ingo Molnar
2013-02-08 21:14                               ` Linus Torvalds
2013-02-08 23:57                                 ` Pekka Enberg
2013-02-09  0:45                                   ` Linus Torvalds
2013-02-09 10:01                                     ` Pekka Enberg
2013-02-09 18:07                                       ` Linus Torvalds
2013-02-09 19:39                                         ` Pekka Enberg
2013-02-09 19:57                                           ` Linus Torvalds
2013-02-09 21:06                                             ` Theodore Ts'o
2013-02-11 12:38                                               ` Ingo Molnar
2013-02-11 12:26                                             ` Ingo Molnar
2013-02-11 12:56                                               ` Ingo Molnar
2013-02-11 13:18                                                 ` David Woodhouse
2013-02-11 13:58                                                   ` Anca Emanuel
2013-02-11 16:34                                                   ` Linus Torvalds
2013-02-11 17:34                                                     ` H. Peter Anvin
2013-02-11 17:41                                                   ` Ingo Molnar
2013-02-11 14:47                                               ` Pekka Enberg
2013-02-11 16:46                                                 ` David Woodhouse
2013-02-11 17:26                                                   ` Anca Emanuel
2013-02-11 16:32                                               ` Linus Torvalds
2013-02-11 17:28                                                 ` Ingo Molnar
     [not found]                                                   ` <CA+55aFx-0-qcYMqH2wnJJ7iAPhoEvD_EQ0xqVW3VGS3G9=_1_w@mail.gmail.com>
2013-02-11 17:58                                                     ` Ingo Molnar
2013-02-11 23:32                                                       ` Linus Torvalds
2013-02-12  9:52                                                         ` Ingo Molnar
2013-02-13  8:23                                                           ` Paolo Bonzini
2013-02-13  8:56                                                             ` Pekka Enberg
2013-02-13  9:23                                                               ` Ingo Molnar
2013-02-14 15:32                                                               ` Anthony Liguori
2013-02-19  8:08                               ` Ingo Molnar
2013-01-12 17:06   ` [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT Borislav Petkov
2013-01-12 17:40     ` H. Peter Anvin
2013-01-12 18:08       ` Borislav Petkov
2013-01-12 18:10         ` H. Peter Anvin
2013-04-12 16:01 ` [PATCH] x86: Default to ARCH=x86 " richard -rw- weinberger
2013-04-12 16:38   ` David Woodhouse

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.