linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] tracing/markers: make markers select tracepoints
@ 2009-02-20 16:34 Frederic Weisbecker
  2009-02-20 16:59 ` Randy Dunlap
  0 siblings, 1 reply; 45+ messages in thread
From: Frederic Weisbecker @ 2009-02-20 16:34 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Steven Rostedt, linux-kernel, zippel, linux-kbuild

Sometimes it happens that KConfig dependencies are not handled
like in the following scenario:

- config A
   bool

- config B
   bool
   depends on A

-config C
   bool
   select B

If one selects C, then it will select B without checking its dependency to A, if A
hasn't been selected elsewhere, it will result in a build crash.

This is what happens on the following build error:

kernel/built-in.o: In function `marker_update_probe_range':
(.text+0x52f64): undefined reference to `tracepoint_probe_register_noupdate'
kernel/built-in.o: In function `marker_update_probe_range':
(.text+0x52f74): undefined reference to `tracepoint_probe_unregister_noupdate'
kernel/built-in.o: In function `marker_update_probe_range':
(.text+0x52fb9): undefined reference to `tracepoint_probe_unregister_noupdate'
kernel/built-in.o: In function `marker_update_probes':
marker.c:(.text+0x530ba): undefined reference to `tracepoint_probe_update_all'

CONFIG_KVM_TRACE will select CONFIG_MARKER, but the latter depends on CONFIG_TRACEPOINTS
which will not be selected.

A temporary fix is to make CONFIG_MARKER select CONFIG_TRACEPOINTS, though it doesn't
fix the source KConfig dependency handling problem.

Reported-by: Ingo Molnar <mingo@elte.hu>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
---
 init/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index b6400a5..a93f957 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -975,7 +975,7 @@ config TRACEPOINTS
 
 config MARKERS
 	bool "Activate markers"
-	depends on TRACEPOINTS
+	select TRACEPOINTS
 	help
 	  Place an empty function call at each marker site. Can be
 	  dynamically changed for a probe function.
-- 
1.6.1



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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-20 16:34 [PATCH] tracing/markers: make markers select tracepoints Frederic Weisbecker
@ 2009-02-20 16:59 ` Randy Dunlap
  2009-02-20 17:20   ` Frederic Weisbecker
                     ` (2 more replies)
  0 siblings, 3 replies; 45+ messages in thread
From: Randy Dunlap @ 2009-02-20 16:59 UTC (permalink / raw)
  To: Frederic Weisbecker
  Cc: Ingo Molnar, Steven Rostedt, linux-kernel, zippel, linux-kbuild

Frederic Weisbecker wrote:
> Sometimes it happens that KConfig dependencies are not handled
> like in the following scenario:
> 
> - config A
>    bool
> 
> - config B
>    bool
>    depends on A
> 
> -config C
>    bool
>    select B
> 
> If one selects C, then it will select B without checking its dependency to A, if A
> hasn't been selected elsewhere, it will result in a build crash.

as documented in Documentation/kbuild/kconfig-language.txt (and yes, it is
considered to be a shortcoming/problem by most people AFAIK):

  Note:
	select should be used with care. select will force
	a symbol to a value without visiting the dependencies.
	By abusing select you are able to select a symbol FOO even
	if FOO depends on BAR that is not set.
	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.
	kconfig should one day warn about such things.

> This is what happens on the following build error:
> 
> kernel/built-in.o: In function `marker_update_probe_range':
> (.text+0x52f64): undefined reference to `tracepoint_probe_register_noupdate'
> kernel/built-in.o: In function `marker_update_probe_range':
> (.text+0x52f74): undefined reference to `tracepoint_probe_unregister_noupdate'
> kernel/built-in.o: In function `marker_update_probe_range':
> (.text+0x52fb9): undefined reference to `tracepoint_probe_unregister_noupdate'
> kernel/built-in.o: In function `marker_update_probes':
> marker.c:(.text+0x530ba): undefined reference to `tracepoint_probe_update_all'
> 
> CONFIG_KVM_TRACE will select CONFIG_MARKER, but the latter depends on CONFIG_TRACEPOINTS
> which will not be selected.
> 
> A temporary fix is to make CONFIG_MARKER select CONFIG_TRACEPOINTS, though it doesn't
> fix the source KConfig dependency handling problem.
> 
> Reported-by: Ingo Molnar <mingo@elte.hu>
> Cc: Roman Zippel <zippel@linux-m68k.org>
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> ---
>  init/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index b6400a5..a93f957 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -975,7 +975,7 @@ config TRACEPOINTS
>  
>  config MARKERS
>  	bool "Activate markers"
> -	depends on TRACEPOINTS
> +	select TRACEPOINTS
>  	help
>  	  Place an empty function call at each marker site. Can be
>  	  dynamically changed for a probe function.

but using "select" instead of "depends on" just causes the kind of problem
that you described, whereas using "depends on" does follow dependency
chains.

-- 
~Randy

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-20 16:59 ` Randy Dunlap
@ 2009-02-20 17:20   ` Frederic Weisbecker
  2009-02-20 17:22   ` Ingo Molnar
  2009-02-21  5:24   ` [PATCH][RFC] check for select dependency errors on config load Steven Rostedt
  2 siblings, 0 replies; 45+ messages in thread
From: Frederic Weisbecker @ 2009-02-20 17:20 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Ingo Molnar, Steven Rostedt, linux-kernel, zippel, linux-kbuild

On Fri, Feb 20, 2009 at 08:59:14AM -0800, Randy Dunlap wrote:
> Frederic Weisbecker wrote:
> > Sometimes it happens that KConfig dependencies are not handled
> > like in the following scenario:
> > 
> > - config A
> >    bool
> > 
> > - config B
> >    bool
> >    depends on A
> > 
> > -config C
> >    bool
> >    select B
> > 
> > If one selects C, then it will select B without checking its dependency to A, if A
> > hasn't been selected elsewhere, it will result in a build crash.
> 
> as documented in Documentation/kbuild/kconfig-language.txt (and yes, it is
> considered to be a shortcoming/problem by most people AFAIK):
> 
>   Note:
> 	select should be used with care. select will force
> 	a symbol to a value without visiting the dependencies.
> 	By abusing select you are able to select a symbol FOO even
> 	if FOO depends on BAR that is not set.
> 	In general use select only for non-visible symbols
> 	(no prompts anywhere) and for symbols with no dependencies.
> 	That will limit the usefulness but on the other hand avoid
> 	the illegal configurations all over.
> 	kconfig should one day warn about such things.


Ah thanks!


 
> > This is what happens on the following build error:
> > 
> > kernel/built-in.o: In function `marker_update_probe_range':
> > (.text+0x52f64): undefined reference to `tracepoint_probe_register_noupdate'
> > kernel/built-in.o: In function `marker_update_probe_range':
> > (.text+0x52f74): undefined reference to `tracepoint_probe_unregister_noupdate'
> > kernel/built-in.o: In function `marker_update_probe_range':
> > (.text+0x52fb9): undefined reference to `tracepoint_probe_unregister_noupdate'
> > kernel/built-in.o: In function `marker_update_probes':
> > marker.c:(.text+0x530ba): undefined reference to `tracepoint_probe_update_all'
> > 
> > CONFIG_KVM_TRACE will select CONFIG_MARKER, but the latter depends on CONFIG_TRACEPOINTS
> > which will not be selected.
> > 
> > A temporary fix is to make CONFIG_MARKER select CONFIG_TRACEPOINTS, though it doesn't
> > fix the source KConfig dependency handling problem.
> > 
> > Reported-by: Ingo Molnar <mingo@elte.hu>
> > Cc: Roman Zippel <zippel@linux-m68k.org>
> > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> > ---
> >  init/Kconfig |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/init/Kconfig b/init/Kconfig
> > index b6400a5..a93f957 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -975,7 +975,7 @@ config TRACEPOINTS
> >  
> >  config MARKERS
> >  	bool "Activate markers"
> > -	depends on TRACEPOINTS
> > +	select TRACEPOINTS
> >  	help
> >  	  Place an empty function call at each marker site. Can be
> >  	  dynamically changed for a probe function.
> 
> but using "select" instead of "depends on" just causes the kind of problem
> that you described, whereas using "depends on" does follow dependency
> chains.


Ok, but here we are in the case described in the above KConfig documentation
which tells that select is mostly useful for config that are not prompted.

This is the case for TRACEPOINTS. So I think this fix is right.

MARKERS/TRACEPOINTS could be likely described as library which can be used
by debugging facilities anywhere in the kernel.

Using only a chain of dependency would hide a lot of those debugging options.
So IMHO, I think such "library" things should be selected directly from other
options and not be enabled by hand, hence only show the debugging options anywhere
in the kernel if those two are selected.

 
> -- 
> ~Randy


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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-20 16:59 ` Randy Dunlap
  2009-02-20 17:20   ` Frederic Weisbecker
@ 2009-02-20 17:22   ` Ingo Molnar
  2009-02-20 17:29     ` Randy Dunlap
                       ` (3 more replies)
  2009-02-21  5:24   ` [PATCH][RFC] check for select dependency errors on config load Steven Rostedt
  2 siblings, 4 replies; 45+ messages in thread
From: Ingo Molnar @ 2009-02-20 17:22 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Frederic Weisbecker, Steven Rostedt, linux-kernel, zippel, linux-kbuild


* Randy Dunlap <randy.dunlap@oracle.com> wrote:

> > This is what happens on the following build error:
> > 
> > kernel/built-in.o: In function `marker_update_probe_range':
> > (.text+0x52f64): undefined reference to `tracepoint_probe_register_noupdate'
> > kernel/built-in.o: In function `marker_update_probe_range':
> > (.text+0x52f74): undefined reference to `tracepoint_probe_unregister_noupdate'
> > kernel/built-in.o: In function `marker_update_probe_range':
> > (.text+0x52fb9): undefined reference to `tracepoint_probe_unregister_noupdate'
> > kernel/built-in.o: In function `marker_update_probes':
> > marker.c:(.text+0x530ba): undefined reference to `tracepoint_probe_update_all'
> > 
> > CONFIG_KVM_TRACE will select CONFIG_MARKER, but the latter 
> > depends on CONFIG_TRACEPOINTS which will not be selected.
> > 
> > A temporary fix is to make CONFIG_MARKER select 
> > CONFIG_TRACEPOINTS, though it doesn't fix the source KConfig 
> > dependency handling problem.
> > 
> > Reported-by: Ingo Molnar <mingo@elte.hu>
> > Cc: Roman Zippel <zippel@linux-m68k.org>
> > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> > ---
> >  init/Kconfig |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/init/Kconfig b/init/Kconfig
> > index b6400a5..a93f957 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -975,7 +975,7 @@ config TRACEPOINTS
> >  
> >  config MARKERS
> >  	bool "Activate markers"
> > -	depends on TRACEPOINTS
> > +	select TRACEPOINTS
> >  	help
> >  	  Place an empty function call at each marker site. Can be
> >  	  dynamically changed for a probe function.
> 
> but using "select" instead of "depends on" just causes the 
> kind of problem that you described, whereas using "depends on" 
> does follow dependency chains.

Well, as long as the secondary selects are 'expanded' along the 
line of dependencies, it should still be fine. With an 
increasing number of dependencies it quickly becomes ugly 
though. This might be one of the cases where it works.

Eventually we should eliminate markers, their uses can either be 
converted to new-style tracepoints, or to ftrace_printk().

	Ingo

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-20 17:22   ` Ingo Molnar
@ 2009-02-20 17:29     ` Randy Dunlap
  2009-02-20 17:31     ` Frederic Weisbecker
                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 45+ messages in thread
From: Randy Dunlap @ 2009-02-20 17:29 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Frederic Weisbecker, Steven Rostedt, linux-kernel, zippel, linux-kbuild

Ingo Molnar wrote:
> * Randy Dunlap <randy.dunlap@oracle.com> wrote:
> 
>>> This is what happens on the following build error:
>>>
>>> kernel/built-in.o: In function `marker_update_probe_range':
>>> (.text+0x52f64): undefined reference to `tracepoint_probe_register_noupdate'
>>> kernel/built-in.o: In function `marker_update_probe_range':
>>> (.text+0x52f74): undefined reference to `tracepoint_probe_unregister_noupdate'
>>> kernel/built-in.o: In function `marker_update_probe_range':
>>> (.text+0x52fb9): undefined reference to `tracepoint_probe_unregister_noupdate'
>>> kernel/built-in.o: In function `marker_update_probes':
>>> marker.c:(.text+0x530ba): undefined reference to `tracepoint_probe_update_all'
>>>
>>> CONFIG_KVM_TRACE will select CONFIG_MARKER, but the latter 
>>> depends on CONFIG_TRACEPOINTS which will not be selected.
>>>
>>> A temporary fix is to make CONFIG_MARKER select 
>>> CONFIG_TRACEPOINTS, though it doesn't fix the source KConfig 
>>> dependency handling problem.
>>>
>>> Reported-by: Ingo Molnar <mingo@elte.hu>
>>> Cc: Roman Zippel <zippel@linux-m68k.org>
>>> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
>>> ---
>>>  init/Kconfig |    2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/init/Kconfig b/init/Kconfig
>>> index b6400a5..a93f957 100644
>>> --- a/init/Kconfig
>>> +++ b/init/Kconfig
>>> @@ -975,7 +975,7 @@ config TRACEPOINTS
>>>  
>>>  config MARKERS
>>>  	bool "Activate markers"
>>> -	depends on TRACEPOINTS
>>> +	select TRACEPOINTS
>>>  	help
>>>  	  Place an empty function call at each marker site. Can be
>>>  	  dynamically changed for a probe function.
>> but using "select" instead of "depends on" just causes the 
>> kind of problem that you described, whereas using "depends on" 
>> does follow dependency chains.
> 
> Well, as long as the secondary selects are 'expanded' along the 
> line of dependencies, it should still be fine. With an 

Agreed.

> increasing number of dependencies it quickly becomes ugly 
> though. This might be one of the cases where it works.

Agreed.

> Eventually we should eliminate markers, their uses can either be 
> converted to new-style tracepoints, or to ftrace_printk().


Thanks,
-- 
~Randy

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-20 17:22   ` Ingo Molnar
  2009-02-20 17:29     ` Randy Dunlap
@ 2009-02-20 17:31     ` Frederic Weisbecker
  2009-02-20 17:48       ` Ingo Molnar
  2009-02-22  3:23     ` KOSAKI Motohiro
  2009-02-22 11:43     ` Peter Zijlstra
  3 siblings, 1 reply; 45+ messages in thread
From: Frederic Weisbecker @ 2009-02-20 17:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Randy Dunlap, Steven Rostedt, linux-kernel, zippel, linux-kbuild

On Fri, Feb 20, 2009 at 06:22:41PM +0100, Ingo Molnar wrote:
> 
> * Randy Dunlap <randy.dunlap@oracle.com> wrote:
> 
> > > This is what happens on the following build error:
> > > 
> > > kernel/built-in.o: In function `marker_update_probe_range':
> > > (.text+0x52f64): undefined reference to `tracepoint_probe_register_noupdate'
> > > kernel/built-in.o: In function `marker_update_probe_range':
> > > (.text+0x52f74): undefined reference to `tracepoint_probe_unregister_noupdate'
> > > kernel/built-in.o: In function `marker_update_probe_range':
> > > (.text+0x52fb9): undefined reference to `tracepoint_probe_unregister_noupdate'
> > > kernel/built-in.o: In function `marker_update_probes':
> > > marker.c:(.text+0x530ba): undefined reference to `tracepoint_probe_update_all'
> > > 
> > > CONFIG_KVM_TRACE will select CONFIG_MARKER, but the latter 
> > > depends on CONFIG_TRACEPOINTS which will not be selected.
> > > 
> > > A temporary fix is to make CONFIG_MARKER select 
> > > CONFIG_TRACEPOINTS, though it doesn't fix the source KConfig 
> > > dependency handling problem.
> > > 
> > > Reported-by: Ingo Molnar <mingo@elte.hu>
> > > Cc: Roman Zippel <zippel@linux-m68k.org>
> > > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> > > ---
> > >  init/Kconfig |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/init/Kconfig b/init/Kconfig
> > > index b6400a5..a93f957 100644
> > > --- a/init/Kconfig
> > > +++ b/init/Kconfig
> > > @@ -975,7 +975,7 @@ config TRACEPOINTS
> > >  
> > >  config MARKERS
> > >  	bool "Activate markers"
> > > -	depends on TRACEPOINTS
> > > +	select TRACEPOINTS
> > >  	help
> > >  	  Place an empty function call at each marker site. Can be
> > >  	  dynamically changed for a probe function.
> > 
> > but using "select" instead of "depends on" just causes the 
> > kind of problem that you described, whereas using "depends on" 
> > does follow dependency chains.
> 
> Well, as long as the secondary selects are 'expanded' along the 
> line of dependencies, it should still be fine. With an 
> increasing number of dependencies it quickly becomes ugly 
> though. This might be one of the cases where it works.
> 
> Eventually we should eliminate markers, their uses can either be 
> converted to new-style tracepoints, or to ftrace_printk().
> 
> 	Ingo

ftrace_printk adds more overhead if not used since it inconditionally
send the trace, unless the related TRACE_ITER_PRINTK flag on ftrace is unset.

I don't know how markers work, but the documentation describes that a single branch
check is done in case the probe is disabled.

With ftrace_printk, even if TRACE_ITER_PRINTK is unset, this is still
one call and one branch check. So for hot callsite it's unappropriate.

IMHO, tracepoints are more suited to replace markers if they have to.


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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-20 17:31     ` Frederic Weisbecker
@ 2009-02-20 17:48       ` Ingo Molnar
  2009-02-20 18:56         ` Jason Baron
                           ` (3 more replies)
  0 siblings, 4 replies; 45+ messages in thread
From: Ingo Molnar @ 2009-02-20 17:48 UTC (permalink / raw)
  To: Frederic Weisbecker, Avi Kivity
  Cc: Randy Dunlap, Steven Rostedt, linux-kernel, linux-kbuild


* Frederic Weisbecker <fweisbec@gmail.com> wrote:

> > > >  config MARKERS
> > > >  	bool "Activate markers"
> > > > -	depends on TRACEPOINTS
> > > > +	select TRACEPOINTS
> > > >  	help
> > > >  	  Place an empty function call at each marker site. Can be
> > > >  	  dynamically changed for a probe function.
> > > 
> > > but using "select" instead of "depends on" just causes the 
> > > kind of problem that you described, whereas using "depends on" 
> > > does follow dependency chains.
> > 
> > Well, as long as the secondary selects are 'expanded' along the 
> > line of dependencies, it should still be fine. With an 
> > increasing number of dependencies it quickly becomes ugly 
> > though. This might be one of the cases where it works.
> > 
> > Eventually we should eliminate markers, their uses can either be 
> > converted to new-style tracepoints, or to ftrace_printk().
> > 
> > 	Ingo
> 
> ftrace_printk adds more overhead if not used since it 
> inconditionally send the trace, unless the related 
> TRACE_ITER_PRINTK flag on ftrace is unset.
> 
> I don't know how markers work, but the documentation describes 
> that a single branch check is done in case the probe is 
> disabled.
> 
> With ftrace_printk, even if TRACE_ITER_PRINTK is unset, this 
> is still one call and one branch check. So for hot callsite 
> it's unappropriate.
> 
> IMHO, tracepoints are more suited to replace markers if they 
> have to.

there's i think the KVM usecase where markers are used 
essentially a printk()-alike flexible tracing facility.

This is how KVMTRACE looks like at the moment:

./vmx.c:	KVMTRACE_3D(MSR_READ, vcpu, ecx, (u32)data, (u32)(data >> 32),
./vmx.c:	KVMTRACE_3D(MSR_WRITE, vcpu, ecx, (u32)data, (u32)(data >> 32),
./vmx.c:	KVMTRACE_0D(PEND_INTR, vcpu, handler);
./vmx.c:	KVMTRACE_3D(VMEXIT, vcpu, exit_reason, (u32)kvm_rip_read(vcpu),
./vmx.c:		KVMTRACE_0D(NMI, vcpu, handler);
./lapic.c:	KVMTRACE_1D(APIC_ACCESS, apic->vcpu, (u32)offset, handler);
./lapic.c:	KVMTRACE_1D(APIC_ACCESS, apic->vcpu, (u32)offset, handler);
./svm.c:	KVMTRACE_2D(DR_READ, vcpu, (u32)dr, (u32)val, handler);
./svm.c:		KVMTRACE_3D(PAGE_FAULT, &svm->vcpu, error_code,
./svm.c:		KVMTRACE_3D(TDP_FAULT, &svm->vcpu, error_code,
./svm.c:	KVMTRACE_0D(NMI, &svm->vcpu, handler);

I think this could easily be converted to a wrapper around 
ftrace_printk() plus a "kvmtrace" ftrace plugin which activates 
those wrapped ftrace_printk() sites via a single global 
__read_mostly flag.

This means KVM tracing is activated via:

 echo kvmtrace > /debug/tracing/current_tracer

that's all.

Basically the conversion would look like this:

before:

        KVMTRACE_3D(MSR_READ, &svm->vcpu, ecx, (u32)data,
                    (u32)(data >> 32), handler);

after:

	kvm_trace("MSR_READ: %p, %08lx, %016Lx\n", &svm->vcpu, ecx, data);

As a result all these traces would become a lot more readable 
(and a lot more flexible) both in the source code, and in the 
trace output stage.

And any ad-hoc tracepoint can be added, without worrying about 
the name of the macro or the number of type of arguments. Note 
that in this specific example we didnt need to split up the u64 
'data' into two 32-bit values, nor do we have to pass in the 
'handler' name, nor do we have to provide a MSR_READ 
enumeration.

The tracing-disabled case would still be as fast - a single 
branch check.

Avi, what do you think, any objections against an RFC patchset 
that shows this off?

	Ingo

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-20 17:48       ` Ingo Molnar
@ 2009-02-20 18:56         ` Jason Baron
  2009-02-21  3:15         ` Frederic Weisbecker
                           ` (2 subsequent siblings)
  3 siblings, 0 replies; 45+ messages in thread
From: Jason Baron @ 2009-02-20 18:56 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Frederic Weisbecker, Avi Kivity, Randy Dunlap, Steven Rostedt,
	linux-kernel, linux-kbuild

On Fri, Feb 20, 2009 at 06:48:11PM +0100, Ingo Molnar wrote:
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 
> > > > >  config MARKERS
> > > > >  	bool "Activate markers"
> > > > > -	depends on TRACEPOINTS
> > > > > +	select TRACEPOINTS
> > > > >  	help
> > > > >  	  Place an empty function call at each marker site. Can be
> > > > >  	  dynamically changed for a probe function.
> > > > 
> > > > but using "select" instead of "depends on" just causes the 
> > > > kind of problem that you described, whereas using "depends on" 
> > > > does follow dependency chains.
> > > 
> > > Well, as long as the secondary selects are 'expanded' along the 
> > > line of dependencies, it should still be fine. With an 
> > > increasing number of dependencies it quickly becomes ugly 
> > > though. This might be one of the cases where it works.
> > > 
> > > Eventually we should eliminate markers, their uses can either be 
> > > converted to new-style tracepoints, or to ftrace_printk().
> > > 
> > > 	Ingo
> > 
> > ftrace_printk adds more overhead if not used since it 
> > inconditionally send the trace, unless the related 
> > TRACE_ITER_PRINTK flag on ftrace is unset.
> > 
> > I don't know how markers work, but the documentation describes 
> > that a single branch check is done in case the probe is 
> > disabled.
> > 
> > With ftrace_printk, even if TRACE_ITER_PRINTK is unset, this 
> > is still one call and one branch check. So for hot callsite 
> > it's unappropriate.
> > 
> > IMHO, tracepoints are more suited to replace markers if they 
> > have to.
> 
> there's i think the KVM usecase where markers are used 
> essentially a printk()-alike flexible tracing facility.
> 
> This is how KVMTRACE looks like at the moment:
> 
> ./vmx.c:	KVMTRACE_3D(MSR_READ, vcpu, ecx, (u32)data, (u32)(data >> 32),
> ./vmx.c:	KVMTRACE_3D(MSR_WRITE, vcpu, ecx, (u32)data, (u32)(data >> 32),
> ./vmx.c:	KVMTRACE_0D(PEND_INTR, vcpu, handler);
> ./vmx.c:	KVMTRACE_3D(VMEXIT, vcpu, exit_reason, (u32)kvm_rip_read(vcpu),
> ./vmx.c:		KVMTRACE_0D(NMI, vcpu, handler);
> ./lapic.c:	KVMTRACE_1D(APIC_ACCESS, apic->vcpu, (u32)offset, handler);
> ./lapic.c:	KVMTRACE_1D(APIC_ACCESS, apic->vcpu, (u32)offset, handler);
> ./svm.c:	KVMTRACE_2D(DR_READ, vcpu, (u32)dr, (u32)val, handler);
> ./svm.c:		KVMTRACE_3D(PAGE_FAULT, &svm->vcpu, error_code,
> ./svm.c:		KVMTRACE_3D(TDP_FAULT, &svm->vcpu, error_code,
> ./svm.c:	KVMTRACE_0D(NMI, &svm->vcpu, handler);
> 
> I think this could easily be converted to a wrapper around 
> ftrace_printk() plus a "kvmtrace" ftrace plugin which activates 
> those wrapped ftrace_printk() sites via a single global 
> __read_mostly flag.
> 
> This means KVM tracing is activated via:
> 
>  echo kvmtrace > /debug/tracing/current_tracer
> 
> that's all.
> 
> Basically the conversion would look like this:
> 
> before:
> 
>         KVMTRACE_3D(MSR_READ, &svm->vcpu, ecx, (u32)data,
>                     (u32)(data >> 32), handler);
> 
> after:
> 
> 	kvm_trace("MSR_READ: %p, %08lx, %016Lx\n", &svm->vcpu, ecx, data);
> 
> As a result all these traces would become a lot more readable 
> (and a lot more flexible) both in the source code, and in the 
> trace output stage.
> 
> And any ad-hoc tracepoint can be added, without worrying about 
> the name of the macro or the number of type of arguments. Note 
> that in this specific example we didnt need to split up the u64 
> 'data' into two 32-bit values, nor do we have to pass in the 
> 'handler' name, nor do we have to provide a MSR_READ 
> enumeration.
> 
> The tracing-disabled case would still be as fast - a single 
> branch check.
> 
> Avi, what do you think, any objections against an RFC patchset 
> that shows this off?
> 

hi,

this is the kind of case that i've designed 'dynamic debug' for. It
implicitly allows fined grained control via - source file and line
number, function name, module name, and/or fomat string. If we are going
to have a bunch of these type of interfaces sprinkled throughout the
kernel, I think this fine grained control becomes important. this is all
controlled and visible via: <debugfs>/dynamic_debug/control file. In the
above case i believe matching 'kvm' module would turn all these
statements on/off. We can always add 'tags' to tie specific debug
statements together as well.

In terms of usage, currently, if you set 'CONFIG_DYNAMIC_DEBUG' all
'pr_debug' and 'dev_dbg' statements are picked up. Thus, simply
converting the above statements to use 'pr_debug()' will make them
run-time tunable if CONFIG_DYNAMIC_DEBUG is set. That's all that needs
to be done...we don't need to write an ftracer debug statements.

We could also make subsystem specific macros as you mentioned
conditional on subsystem specific CONFIG parameters. For example, if 
'CONFIG_KVM_DEBUG' is set we tie it into this infrastructure otherwise its a
no-op.

In terms of the 'backend', currently we're using 'printk'. However, i've
posted patches in to tie into ftrace_printk(). This could easily be made
toggle switch.

That said, markers do allow for callbacks, so that different parts of
the kernel can register and get called when the marker is hit. This
behavior might be more appropriate if its not simple 'printk' style
debugging.

thanks,

-Jason



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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-20 17:48       ` Ingo Molnar
  2009-02-20 18:56         ` Jason Baron
@ 2009-02-21  3:15         ` Frederic Weisbecker
  2009-02-21 22:04         ` Frank Ch. Eigler
  2009-02-23 10:13         ` Avi Kivity
  3 siblings, 0 replies; 45+ messages in thread
From: Frederic Weisbecker @ 2009-02-21  3:15 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Avi Kivity, Randy Dunlap, Steven Rostedt, linux-kernel, linux-kbuild

On Fri, Feb 20, 2009 at 06:48:11PM +0100, Ingo Molnar wrote:
> 
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 
> > > > >  config MARKERS
> > > > >  	bool "Activate markers"
> > > > > -	depends on TRACEPOINTS
> > > > > +	select TRACEPOINTS
> > > > >  	help
> > > > >  	  Place an empty function call at each marker site. Can be
> > > > >  	  dynamically changed for a probe function.
> > > > 
> > > > but using "select" instead of "depends on" just causes the 
> > > > kind of problem that you described, whereas using "depends on" 
> > > > does follow dependency chains.
> > > 
> > > Well, as long as the secondary selects are 'expanded' along the 
> > > line of dependencies, it should still be fine. With an 
> > > increasing number of dependencies it quickly becomes ugly 
> > > though. This might be one of the cases where it works.
> > > 
> > > Eventually we should eliminate markers, their uses can either be 
> > > converted to new-style tracepoints, or to ftrace_printk().
> > > 
> > > 	Ingo
> > 
> > ftrace_printk adds more overhead if not used since it 
> > inconditionally send the trace, unless the related 
> > TRACE_ITER_PRINTK flag on ftrace is unset.
> > 
> > I don't know how markers work, but the documentation describes 
> > that a single branch check is done in case the probe is 
> > disabled.
> > 
> > With ftrace_printk, even if TRACE_ITER_PRINTK is unset, this 
> > is still one call and one branch check. So for hot callsite 
> > it's unappropriate.
> > 
> > IMHO, tracepoints are more suited to replace markers if they 
> > have to.
> 
> there's i think the KVM usecase where markers are used 
> essentially a printk()-alike flexible tracing facility.
> 
> This is how KVMTRACE looks like at the moment:
> 
> ./vmx.c:	KVMTRACE_3D(MSR_READ, vcpu, ecx, (u32)data, (u32)(data >> 32),
> ./vmx.c:	KVMTRACE_3D(MSR_WRITE, vcpu, ecx, (u32)data, (u32)(data >> 32),
> ./vmx.c:	KVMTRACE_0D(PEND_INTR, vcpu, handler);
> ./vmx.c:	KVMTRACE_3D(VMEXIT, vcpu, exit_reason, (u32)kvm_rip_read(vcpu),
> ./vmx.c:		KVMTRACE_0D(NMI, vcpu, handler);
> ./lapic.c:	KVMTRACE_1D(APIC_ACCESS, apic->vcpu, (u32)offset, handler);
> ./lapic.c:	KVMTRACE_1D(APIC_ACCESS, apic->vcpu, (u32)offset, handler);
> ./svm.c:	KVMTRACE_2D(DR_READ, vcpu, (u32)dr, (u32)val, handler);
> ./svm.c:		KVMTRACE_3D(PAGE_FAULT, &svm->vcpu, error_code,
> ./svm.c:		KVMTRACE_3D(TDP_FAULT, &svm->vcpu, error_code,
> ./svm.c:	KVMTRACE_0D(NMI, &svm->vcpu, handler);
> 
> I think this could easily be converted to a wrapper around 
> ftrace_printk() plus a "kvmtrace" ftrace plugin which activates 
> those wrapped ftrace_printk() sites via a single global 
> __read_mostly flag.
> 
> This means KVM tracing is activated via:
> 
>  echo kvmtrace > /debug/tracing/current_tracer
> 
> that's all.


Note that I haven't looked at kvm tracing in detail, so I could be wrong.
But when I look of the kind of events above which are traced through KVM,
I guess the frequency rate of traces can be high.

The use of ftrace_printk seems to me an overhead here for ring buffer space consuming
and tracing overhead itself.

ftrace_printk inserts the events on the ring buffer as already formatted, so
it consumes more space that traditional binary insertion. But I skip that since we have
16384 entries by default (large enough), though the notion of entry size is dynamic
with the ring buffer.

But doing the vsnprintf on tracing context seems to me inappropriate since
tracing should be as much transparent as possible from the traced site point
of view. I think it should be better on output time, unless the traces rate is not
as high as I imagine.

 
> Basically the conversion would look like this:
> 
> before:
> 
>         KVMTRACE_3D(MSR_READ, &svm->vcpu, ecx, (u32)data,
>                     (u32)(data >> 32), handler);
> 
> after:
> 
> 	kvm_trace("MSR_READ: %p, %08lx, %016Lx\n", &svm->vcpu, ecx, data);
> 
> As a result all these traces would become a lot more readable 
> (and a lot more flexible) both in the source code, and in the 
> trace output stage.


Right.
Anyway, it needs to be integrated into the common tracing part
of the kernel. virt/kvm_trace.c is a whole tracer.


> And any ad-hoc tracepoint can be added, without worrying about 
> the name of the macro or the number of type of arguments. Note 
> that in this specific example we didnt need to split up the u64 
> 'data' into two 32-bit values, nor do we have to pass in the 
> 'handler' name, nor do we have to provide a MSR_READ 
> enumeration.
> 
> The tracing-disabled case would still be as fast - a single 
> branch check.
> 
> Avi, what do you think, any objections against an RFC patchset 
> that shows this off?
> 
> 	Ingo


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

* [PATCH][RFC] check for select dependency errors on config load
  2009-02-20 16:59 ` Randy Dunlap
  2009-02-20 17:20   ` Frederic Weisbecker
  2009-02-20 17:22   ` Ingo Molnar
@ 2009-02-21  5:24   ` Steven Rostedt
  2009-02-21  5:58     ` Andrew Morton
                       ` (2 more replies)
  2 siblings, 3 replies; 45+ messages in thread
From: Steven Rostedt @ 2009-02-21  5:24 UTC (permalink / raw)
  To: LKML, linux-kbuild
  Cc: Randy Dunlap, Frederic Weisbecker, Ingo Molnar, zippel, Andrew Morton

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


There's been a few problems with SELECT and dependencies lately.
I've been burnt by it a few times myself. So I look at the kconfig
code and added this patch. It can use a bit more work but it does what
I want.

When the config is loaded, it checks all the symbols that are
selected by an active config and makes sure the visible dependencies are 
also activated. This should probably be moved to the writing of the 
config instead, but since I just wanted to see if my current config was 
OK, I did it on load. This is an RFC patch anyway, so fixes/comments are 
definitely welcome.

Here's what I get with the attached config running on 2.6.29-rc5.

$ make menuconfig
scripts/kconfig/mconf arch/x86/Kconfig
.config:2561:warning: MICROCODE selects FW_LOADER which fails its dependencies!
.config:2561:warning: MICROCODE_INTEL selects FW_LOADER which fails its dependencies!
.config:2561:warning: PCMCIA_LOAD_CIS selects FW_LOADER which fails its dependencies!
.config:2561:warning: SCSI_SAS_LIBSAS selects SCSI_SAS_ATTRS which fails its dependencies!
.config:2561:warning: SCSI_AIC94XX selects FW_LOADER which fails its dependencies!
.config:2561:warning: KEYBOARD_ATKBD selects SERIO which fails its dependencies!
.config:2561:warning: KEYBOARD_ATKBD selects SERIO_LIBPS2 which fails its dependencies!
.config:2561:warning: KEYBOARD_ATKBD selects SERIO_I8042 which fails its dependencies!
.config:2561:warning: MOUSE_PS2 selects SERIO which fails its dependencies!
.config:2561:warning: MOUSE_PS2 selects SERIO_LIBPS2 which fails its dependencies!
.config:2561:warning: MOUSE_PS2 selects SERIO_I8042 which fails its dependencies!
.config:2561:warning: VT selects INPUT which fails its dependencies!
.config:2561:warning: DRM selects I2C_ALGOBIT which fails its dependencies!
.config:2561:warning: SND_EMU10K1 selects FW_LOADER which fails its dependencies!

<exit out>

*** End of Linux kernel configuration.
*** Execute 'make' to build the kernel or try 'make help'.

This also flags the MARKERS error with KVM_TRACE in linux-tip.

Signed-off-by: Steven Rostedt <srostedt@redhat.com>


diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 830d9ea..abe31e1 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -310,6 +310,109 @@ load:
 	return 0;
 }
 
+static int test_deps(struct symbol *sym)
+{
+	struct property *prop;
+	struct expr *expr;
+
+	if (sym->rev_dep.tri == no)
+		return 1;
+
+	for (prop = sym->prop; prop; prop = prop->next) {
+		if (prop->type != P_PROMPT)
+			continue;
+
+		expr = prop->visible.expr;
+		if (!expr)
+			continue;
+
+		if (expr_calc_value(expr) == no)
+			return 0;
+	}
+
+	return 1;
+}
+
+void test_select(struct symbol *sym)
+{
+	struct property *prop;
+	struct expr *expr;
+
+	for (prop = sym->prop; prop; prop = prop->next) {
+		if (prop->type != P_SELECT)
+			continue;
+
+		expr = prop->expr;
+
+		if (!expr || expr->type != E_SYMBOL ||
+		    !expr->left.sym)
+			continue;
+			
+		if (test_deps(expr->left.sym))
+			continue;
+
+		conf_warning("%s selects %s which fails its dependencies!",
+			     sym->name, expr->left.sym->name);
+	}
+}
+
+void test_conf(void)
+{
+	struct symbol *sym;
+	struct menu *menu;
+	int type;
+
+	menu = rootmenu.list;
+	while (menu) {
+		sym = menu->sym;
+		if (!sym)
+			goto next;
+
+		if (!(sym->flags & SYMBOL_CHOICE)) {
+			sym_calc_value(sym);
+			if (!(sym->flags & SYMBOL_WRITE))
+				goto next;
+			type = sym->type;
+			if (type == S_TRISTATE) {
+				sym_calc_value(modules_sym);
+				if (modules_sym->curr.tri == no)
+					type = S_BOOLEAN;
+			}
+			switch (type) {
+			case S_BOOLEAN:
+			case S_TRISTATE:
+				switch (sym_get_tristate_value(sym)) {
+				case no:
+					break;
+				case mod:
+				case yes:
+					test_select(sym);
+					break;
+				}
+				break;
+			case S_STRING:
+			case S_HEX:
+			case S_INT:
+				break;
+			}
+		}
+
+	next:
+		if (menu->list) {
+			menu = menu->list;
+			continue;
+		}
+		if (menu->next)
+			menu = menu->next;
+		else while ((menu = menu->parent)) {
+			if (menu->next) {
+				menu = menu->next;
+				break;
+			}
+		}
+	}
+}
+
 int conf_read(const char *name)
 {
 	struct symbol *sym, *choice_sym;
@@ -386,6 +489,7 @@ int conf_read(const char *name)
 
 	sym_add_change_count(conf_warnings || conf_unsaved);
 
+	test_conf();
 	return 0;
 }
 


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

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.29-rc5
# Fri Feb 20 23:46:12 2009
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_TREE=y

#
# RCU Subsystem
#
CONFIG_CLASSIC_RCU=y
# CONFIG_TREE_RCU is not set
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_PREEMPT_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not set
# CONFIG_CGROUPS is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
# CONFIG_OPROFILE is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
# CONFIG_SPARSE_IRQ is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_VSMP is not set
# CONFIG_X86_RDC321X is not set
CONFIG_SCHED_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT_GUEST is not set
CONFIG_MEMTEST=y
# CONFIG_M386 is not set
# 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_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_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CPU=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_CYRIX_32=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR_32=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_CPU_SUP_UMC_32=y
CONFIG_X86_DS=y
CONFIG_X86_PTRACE_BTS=y
CONFIG_HPET_TIMER=y
CONFIG_DMI=y
# CONFIG_IOMMU_HELPER is not set
# CONFIG_IOMMU_API is not set
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_X86_MCE_P4THERMAL is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_UNEVICTABLE_LRU=y
CONFIG_MMU_NOTIFIER=y
# CONFIG_HIGHPTE is not set
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW_64K=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
CONFIG_EFI=y
# CONFIG_SECCOMP is not set
# 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=y
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x200000
CONFIG_HOTPLUG_CPU=y
CONFIG_COMPAT_VDSO=y
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_HIBERNATION is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=1999
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_SBS=m
CONFIG_X86_APM_BOOT=y
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_ALLOW_INTS is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_DEBUG=y
# CONFIG_CPU_FREQ_STAT is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_POWERNOW_K6 is not set
CONFIG_X86_POWERNOW_K7=y
CONFIG_X86_POWERNOW_K7_ACPI=y
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_POWERNOW_K8_ACPI=y
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=y
CONFIG_X86_SPEEDSTEP_SMI=y
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
CONFIG_X86_LONGRUN=y
# CONFIG_X86_LONGHAUL is not set
# CONFIG_X86_E_POWERSAVER is not set

#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=y
# CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=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_DOMAINS=y
CONFIG_PCIEPORTBUS=y
# CONFIG_HOTPLUG_PCI_PCIE is not set
CONFIG_PCIEAER=y
# CONFIG_PCIEASPM is not set
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_OLPC is not set
CONFIG_K8_NB=y
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set
CONFIG_PCMCIA_PROBE=y
CONFIG_PCCARD_NONSTATIC=y
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_IBM is not set
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set

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

#
# Networking options
#
CONFIG_COMPAT_NET_DEV_OPS=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=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_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=y
CONFIG_TCP_CONG_CUBIC=y
# CONFIG_TCP_CONG_WESTWOOD is not set
# CONFIG_TCP_CONG_HTCP is not set
# CONFIG_TCP_CONG_HSTCP is not set
# CONFIG_TCP_CONG_HYBLA is not set
# CONFIG_TCP_CONG_VEGAS is not set
# CONFIG_TCP_CONG_SCALABLE is not set
# CONFIG_TCP_CONG_LP is not set
# CONFIG_TCP_CONG_VENO is not set
# CONFIG_TCP_CONG_YEAH is not set
# CONFIG_TCP_CONG_ILLINOIS is not set
CONFIG_DEFAULT_BIC=y
# CONFIG_DEFAULT_CUBIC is not set
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="bic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
# CONFIG_INET6_XFRM_MODE_BEET is not set
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
# CONFIG_IPV6_SIT is not set
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CT_ACCT=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
# CONFIG_NF_CT_PROTO_DCCP is not set
# CONFIG_NF_CT_PROTO_SCTP is not set
# CONFIG_NF_CT_PROTO_UDPLITE is not set
# CONFIG_NF_CONNTRACK_AMANDA is not set
# CONFIG_NF_CONNTRACK_FTP is not set
# CONFIG_NF_CONNTRACK_H323 is not set
# CONFIG_NF_CONNTRACK_IRC is not set
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_CONNTRACK_SANE is not set
# CONFIG_NF_CONNTRACK_SIP is not set
# CONFIG_NF_CONNTRACK_TFTP is not set
# CONFIG_NF_CT_NETLINK is not set
CONFIG_NETFILTER_XTABLES=m
# CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set
# CONFIG_NETFILTER_XT_TARGET_CONNMARK is not set
# CONFIG_NETFILTER_XT_TARGET_CONNSECMARK is not set
# CONFIG_NETFILTER_XT_TARGET_MARK is not set
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
# CONFIG_NETFILTER_XT_TARGET_RATEEST is not set
# CONFIG_NETFILTER_XT_TARGET_SECMARK is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set
# CONFIG_NETFILTER_XT_MATCH_CONNLIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNMARK is not set
# CONFIG_NETFILTER_XT_MATCH_CONNTRACK is not set
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_HELPER is not set
# CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
# CONFIG_NETFILTER_XT_MATCH_LIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_MAC is not set
# CONFIG_NETFILTER_XT_MATCH_MARK is not set
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
# CONFIG_NETFILTER_XT_MATCH_POLICY is not set
# CONFIG_NETFILTER_XT_MATCH_PHYSDEV is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_RATEEST is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
# CONFIG_NETFILTER_XT_MATCH_RECENT is not set
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
CONFIG_NETFILTER_XT_MATCH_STATE=m
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
# CONFIG_NETFILTER_XT_MATCH_STRING is not set
# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
# CONFIG_IP_NF_MATCH_AH is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
# CONFIG_IP_NF_TARGET_LOG is not set
# CONFIG_IP_NF_TARGET_ULOG is not set
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
# CONFIG_IP_NF_TARGET_NETMAP is not set
# CONFIG_IP_NF_TARGET_REDIRECT is not set
# CONFIG_NF_NAT_SNMP_BASIC is not set
# CONFIG_NF_NAT_FTP is not set
# CONFIG_NF_NAT_IRC is not set
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
# CONFIG_NF_NAT_SIP is not set
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_SECURITY is not set
# CONFIG_IP_NF_ARPTABLES is not set

#
# IPv6: Netfilter Configuration
#
# CONFIG_NF_CONNTRACK_IPV6 is not set
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=m
# CONFIG_IP6_NF_MATCH_AH is not set
# CONFIG_IP6_NF_MATCH_EUI64 is not set
# CONFIG_IP6_NF_MATCH_FRAG is not set
# CONFIG_IP6_NF_MATCH_OPTS is not set
# CONFIG_IP6_NF_MATCH_HL is not set
# CONFIG_IP6_NF_MATCH_IPV6HEADER is not set
# CONFIG_IP6_NF_MATCH_MH is not set
# CONFIG_IP6_NF_MATCH_RT is not set
# CONFIG_IP6_NF_TARGET_LOG is not set
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_REJECT=m
# CONFIG_IP6_NF_MANGLE is not set
# CONFIG_IP6_NF_RAW is not set
# CONFIG_IP6_NF_SECURITY is not set
# CONFIG_BRIDGE_NF_EBTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
CONFIG_STP=m
CONFIG_BRIDGE=m
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
# CONFIG_NET_SCH_CBQ is not set
# CONFIG_NET_SCH_HTB is not set
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_MULTIQ is not set
# CONFIG_NET_SCH_RED is not set
# CONFIG_NET_SCH_SFQ is not set
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_DRR is not set
# CONFIG_NET_SCH_INGRESS is not set

#
# Classification
#
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
# CONFIG_NET_CLS_TCINDEX is not set
# CONFIG_NET_CLS_ROUTE4 is not set
# CONFIG_NET_CLS_FW is not set
# CONFIG_NET_CLS_U32 is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_FLOW is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
# CONFIG_NET_EMATCH_CMP is not set
# CONFIG_NET_EMATCH_NBYTE is not set
# CONFIG_NET_EMATCH_U32 is not set
# CONFIG_NET_EMATCH_META is not set
# CONFIG_NET_EMATCH_TEXT is not set
CONFIG_NET_CLS_ACT=y
# CONFIG_NET_ACT_POLICE is not set
# CONFIG_NET_ACT_GACT is not set
# CONFIG_NET_ACT_MIRRED is not set
# CONFIG_NET_ACT_IPT is not set
# CONFIG_NET_ACT_NAT is not set
# CONFIG_NET_ACT_PEDIT is not set
# CONFIG_NET_ACT_SIMP is not set
# CONFIG_NET_ACT_SKBEDIT is not set
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
# CONFIG_BT_SCO is not set
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
# CONFIG_BT_BNEP is not set
CONFIG_BT_HIDP=m

#
# Bluetooth device drivers
#
# CONFIG_BT_HCIBTUSB is not set
# CONFIG_BT_HCIUART is not set
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BT_HCIBPA10X is not set
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIDTL1 is not set
# CONFIG_BT_HCIBT3C is not set
# CONFIG_BT_HCIBLUECARD is not set
# CONFIG_BT_HCIBTUART is not set
# CONFIG_BT_HCIVHCI is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_PHONET is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
# CONFIG_LIB80211 is not set
# CONFIG_MAC80211 is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_PC_PCMCIA is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_ISAPNP=y
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE 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=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_93CX6 is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

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

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=y

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
# CONFIG_SCSI_FC_ATTRS is not set
# 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_SAS_LIBSAS_DEBUG is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_SCSI_CXGB3_ISCSI is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=4
CONFIG_AIC7XXX_RESET_DELAY_MS=1000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
CONFIG_SCSI_AIC79XX=y
CONFIG_AIC79XX_CMDS_PER_DEVICE=4
CONFIG_AIC79XX_RESET_DELAY_MS=1000
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC94XX=y
# CONFIG_AIC94XX_DEBUG is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_ARCMSR is not set
CONFIG_MEGARAID_NEWGEN=y
# CONFIG_MEGARAID_MM is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_LIBFC is not set
# CONFIG_FCOE is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
# CONFIG_SCSI_DH is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y
CONFIG_SATA_AHCI=y
CONFIG_SATA_SIL24=y
CONFIG_ATA_SFF=y
CONFIG_SATA_SVW=y
CONFIG_ATA_PIIX=y
CONFIG_SATA_MV=y
CONFIG_SATA_NV=y
CONFIG_PDC_ADMA=y
CONFIG_SATA_QSTOR=y
CONFIG_SATA_PROMISE=y
CONFIG_SATA_SX4=y
CONFIG_SATA_SIL=y
CONFIG_SATA_SIS=y
CONFIG_SATA_ULI=y
CONFIG_SATA_VIA=y
CONFIG_SATA_VITESSE=y
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
CONFIG_PATA_ALI=y
CONFIG_PATA_AMD=y
CONFIG_PATA_ARTOP=y
CONFIG_PATA_ATIIXP=y
# CONFIG_PATA_CMD640_PCI is not set
CONFIG_PATA_CMD64X=y
CONFIG_PATA_CS5520=y
CONFIG_PATA_CS5530=y
CONFIG_PATA_CS5535=y
# CONFIG_PATA_CS5536 is not set
CONFIG_PATA_CYPRESS=y
CONFIG_PATA_EFAR=y
CONFIG_ATA_GENERIC=y
CONFIG_PATA_HPT366=y
CONFIG_PATA_HPT37X=y
CONFIG_PATA_HPT3X2N=y
CONFIG_PATA_HPT3X3=y
# CONFIG_PATA_HPT3X3_DMA is not set
# CONFIG_PATA_ISAPNP is not set
CONFIG_PATA_IT821X=y
# CONFIG_PATA_IT8213 is not set
CONFIG_PATA_JMICRON=y
# CONFIG_PATA_LEGACY is not set
CONFIG_PATA_TRIFLEX=y
CONFIG_PATA_MARVELL=y
CONFIG_PATA_MPIIX=y
CONFIG_PATA_OLDPIIX=y
CONFIG_PATA_NETCELL=y
# CONFIG_PATA_NINJA32 is not set
CONFIG_PATA_NS87410=y
# CONFIG_PATA_NS87415 is not set
CONFIG_PATA_OPTI=y
CONFIG_PATA_OPTIDMA=y
# CONFIG_PATA_PCMCIA is not set
CONFIG_PATA_PDC_OLD=y
CONFIG_PATA_QDI=y
CONFIG_PATA_RADISYS=y
CONFIG_PATA_RZ1000=y
CONFIG_PATA_SC1200=y
CONFIG_PATA_SERVERWORKS=y
CONFIG_PATA_PDC2027X=y
CONFIG_PATA_SIL680=y
CONFIG_PATA_SIS=y
CONFIG_PATA_VIA=y
CONFIG_PATA_WINBOND=y
CONFIG_PATA_WINBOND_VLB=y
# CONFIG_PATA_SCH is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID456 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
# CONFIG_DM_CRYPT is not set
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT is not set
CONFIG_FUSION=y
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
CONFIG_FUSION_MAX_SGE=40
# CONFIG_FUSION_LOGGING is not set

#
# IEEE 1394 (FireWire) support
#

#
# Enable only one of the two stacks, unless you know what you are doing
#
# CONFIG_FIREWIRE is not set
CONFIG_IEEE1394=m
CONFIG_IEEE1394_OHCI1394=m
# CONFIG_IEEE1394_PCILYNX is not set
# CONFIG_IEEE1394_SBP2 is not set
# CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set
# CONFIG_IEEE1394_ETH1394 is not set
# CONFIG_IEEE1394_RAWIO is not set
# CONFIG_IEEE1394_VIDEO1394 is not set
# CONFIG_IEEE1394_DV1394 is not set
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_IFB is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
# CONFIG_VORTEX is not set
# CONFIG_TYPHOON is not set
# CONFIG_LANCE is not set
CONFIG_NET_VENDOR_SMC=y
# CONFIG_WD80x3 is not set
# CONFIG_ULTRA is not set
# CONFIG_SMC9194 is not set
# CONFIG_NET_VENDOR_RACAL is not set
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_ULI526X is not set
# CONFIG_PCMCIA_XIRCOM is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
CONFIG_NET_ISA=y
# CONFIG_E2100 is not set
# CONFIG_EWRK3 is not set
# CONFIG_EEXPRESS is not set
# CONFIG_EEXPRESS_PRO is not set
# CONFIG_HPLAN_PLUS is not set
# CONFIG_HPLAN is not set
# CONFIG_LP486E is not set
# CONFIG_ETH16I is not set
# CONFIG_NE2000 is not set
# CONFIG_ZNET is not set
# CONFIG_SEEQ8005 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
CONFIG_FORCEDETH=y
CONFIG_FORCEDETH_NAPI=y
# CONFIG_CS89x0 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
CONFIG_8139CP=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_R6040 is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SMSC9420 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
CONFIG_NET_POCKET=y
# CONFIG_ATP is not set
# CONFIG_DE600 is not set
# CONFIG_DE620 is not set
# CONFIG_ATL2 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
# CONFIG_E1000E is not set
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
CONFIG_SKGE=y
# CONFIG_SKGE_DEBUG is not set
# CONFIG_SKY2 is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=y
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_JME is not set
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
CONFIG_CHELSIO_T3_DEPENDS=y
# CONFIG_CHELSIO_T3 is not set
# CONFIG_ENIC is not set
# CONFIG_IXGBE is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
# CONFIG_NIU is not set
# CONFIG_MLX4_EN is not set
# CONFIG_MLX4_CORE is not set
# CONFIG_TEHUTI is not set
# CONFIG_BNX2X is not set
# CONFIG_QLGE is not set
# CONFIG_SFC is not set
CONFIG_TR=y
# CONFIG_IBMTR is not set
# CONFIG_IBMOL is not set
# CONFIG_IBMLS is not set
# CONFIG_3C359 is not set
# CONFIG_TMS380TR is not set
# CONFIG_SMCTR is not set

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
# CONFIG_IWLWIFI_LEDS is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
CONFIG_NET_PCMCIA=y
# CONFIG_PCMCIA_3C589 is not set
# CONFIG_PCMCIA_3C574 is not set
# CONFIG_PCMCIA_FMVJ18X is not set
# CONFIG_PCMCIA_PCNET is not set
# CONFIG_PCMCIA_NMCLAN is not set
# CONFIG_PCMCIA_SMC91C92 is not set
# CONFIG_PCMCIA_XIRC2PS is not set
# CONFIG_PCMCIA_AXNET is not set
# CONFIG_PCMCIA_IBMTR is not set
# CONFIG_WAN is not set
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
# CONFIG_SKFP is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
CONFIG_NET_FC=y
CONFIG_NETCONSOLE=y
# CONFIG_NETCONSOLE_DYNAMIC is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA 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 is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_ZHENHUA is not set
# CONFIG_JOYSTICK_DB9 is not set
# CONFIG_JOYSTICK_GAMECON is not set
# CONFIG_JOYSTICK_TURBOGRAFX is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD is not set
# CONFIG_JOYSTICK_WALKERA0701 is not set
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_HTCPEN is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_WM97XX is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
# CONFIG_INPUT_UINPUT is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_DEVKMEM=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_SYNCLINK_GT is not set
# CONFIG_N_HDLC is not set
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
# CONFIG_SERIAL_8250_CS is not set
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
# CONFIG_SERIAL_8250_FOURPORT is not set
# CONFIG_SERIAL_8250_ACCENT is not set
# CONFIG_SERIAL_8250_BOCA is not set
# CONFIG_SERIAL_8250_EXAR_ST16C554 is not set
# CONFIG_SERIAL_8250_HUB6 is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
# CONFIG_PPDEV is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_INTEL is not set
# CONFIG_HW_RANDOM_AMD is not set
# CONFIG_HW_RANDOM_GEODE is not set
# CONFIG_HW_RANDOM_VIA is not set
CONFIG_NVRAM=y
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_IPWIRELESS is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=8192
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_CHARDEV is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y

#
# I2C Hardware Bus support
#

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

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_SIMTEC is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Graphics adapter I2C/DDC channel drivers
#
# CONFIG_I2C_VOODOO3 is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_PCA_ISA is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_STUB is not set
# CONFIG_SCx200_ACB is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_PCF8575 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
# CONFIG_SPI is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB 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_BATTERY_DS2760 is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_HWMON is not set
CONFIG_THERMAL=y
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_IBMASR is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I6300ESB_WDT is not set
CONFIG_ITCO_WDT=m
CONFIG_ITCO_VENDOR_SUPPORT=y
# CONFIG_IT8712F_WDT is not set
# CONFIG_IT87_WDT is not set
# CONFIG_HP_WATCHDOG is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_SBC7240_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC_SCH311X_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83697HF_WDT is not set
# CONFIG_W83697UG_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
# CONFIG_MACHZ_WDT is not set
# CONFIG_SBC_EPX_C3_WATCHDOG is not set

#
# 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 is not set
# CONFIG_WDTPCI is not set

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

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_REGULATOR is not set

#
# Multimedia devices
#

#
# Multimedia core support
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_VIDEO_MEDIA is not set

#
# Multimedia drivers
#
# CONFIG_DAB is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_ALI=y
CONFIG_AGP_ATI=y
CONFIG_AGP_AMD=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_NVIDIA=y
CONFIG_AGP_SIS=y
CONFIG_AGP_SWORKS=y
CONFIG_AGP_VIA=y
CONFIG_AGP_EFFICEON=y
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
CONFIG_DRM_I810=y
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=y
# CONFIG_DRM_I915_KMS is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# 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 is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# 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 is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
# CONFIG_FB_VESA is not set
# CONFIG_FB_EFI is not set
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_PROGEAR is not set
# CONFIG_BACKLIGHT_MBP_NVIDIA is not set
# CONFIG_BACKLIGHT_SAHARA is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE is not set
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=y
CONFIG_SOUND_OSS_CORE=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HWDEP=y
CONFIG_SND_RAWMIDI=y
CONFIG_SND_JACK=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_SEQ_DUMMY=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_MPU401_UART=y
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_DRIVERS=y
# CONFIG_SND_PCSP is not set
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=y
# CONFIG_SND_PORTMAN2X4 is not set
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0
CONFIG_SND_ISA=y
# CONFIG_SND_ADLIB is not set
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_SC6000 is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_MIRO is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
CONFIG_SND_EMU10K1=y
CONFIG_SND_EMU10K1X=y
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=y
# CONFIG_SND_HDA_HWDEP is not set
# CONFIG_SND_HDA_INPUT_BEEP is not set
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_ATIHDMI=y
CONFIG_SND_HDA_CODEC_NVHDMI=y
CONFIG_SND_HDA_CODEC_INTELHDMI=y
CONFIG_SND_HDA_ELD=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
# CONFIG_SND_HDA_POWER_SAVE is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_HIFIER is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=y
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SIS7019 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_USB=y
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set
# CONFIG_SND_USB_US122L is not set
CONFIG_SND_PCMCIA=y
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_PDAUDIOCF is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=y
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HID_DEBUG=y
# CONFIG_HIDRAW is not set

#
# USB Input Devices
#
# CONFIG_USB_HID is not set
# CONFIG_HID_PID is not set

#
# Special HID drivers
#
CONFIG_HID_COMPAT=y
CONFIG_HID_APPLE=m
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
# CONFIG_USB_HWA_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may also be needed;
#

#
# see USB_STORAGE Help for more information
#
# CONFIG_USB_STORAGE is not set
CONFIG_USB_LIBUSUAL=y

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_VST is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_ALIX2 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
# CONFIG_LEDS_TRIGGER_TIMER is not set
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
# CONFIG_EDAC_MM_EDAC is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_TC1100_WMI is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_PANASONIC_LAPTOP is not set
# CONFIG_COMPAL_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_INTEL_MENLOW is not set
# CONFIG_EEEPC_LAPTOP is not set
# CONFIG_ACPI_WMI is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set

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

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT2_FS_XIP=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4_FS is not set
CONFIG_FS_XIP=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_PRINT_QUOTA_WARNING=y
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
# CONFIG_CONFIGFS_FS is not set
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 is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS 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 is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
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 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# 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 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB 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 is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_HW_BRANCH_TRACER=y

#
# Tracers
#
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SYSPROF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_CONTEXT_SWITCH_TRACER is not set
# CONFIG_BOOT_TRACER is not set
# CONFIG_TRACE_BRANCH_PROFILING is not set
# CONFIG_POWER_TRACER is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_HW_BRANCH_TRACER is not set
# CONFIG_MMIOTRACE is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_DYNAMIC_PRINTK_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_X86_PTDUMP is not set
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_RODATA_TEST=y
# CONFIG_DEBUG_NX_TEST is not set
CONFIG_4KSTACKS=y
CONFIG_DOUBLEFAULT=y
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=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_DEBUG_BOOT_PARAMS is not set
# CONFIG_CPA_DEBUG is not set
# CONFIG_OPTIMIZE_INLINING is not set

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_SECURITY=y
# CONFIG_SECURITYFS is not set
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
# CONFIG_SECURITY_PATH is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
# CONFIG_CRYPTO_FIPS is not set
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_NULL=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set

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

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

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=y

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32C_INTEL is not set
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
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 is not set
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_BLOWFISH=y
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
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 is not set
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_TWOFISH_COMMON=y
# CONFIG_CRYPTO_TWOFISH_586 is not set

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

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_CRYPTO_DEV_GEODE is not set
# CONFIG_CRYPTO_DEV_HIFN_795X is not set
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=y
CONFIG_KVM_INTEL=y
CONFIG_KVM_AMD=y
# CONFIG_LGUEST is not set
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y

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

* Re: [PATCH][RFC] check for select dependency errors on config load
  2009-02-21  5:24   ` [PATCH][RFC] check for select dependency errors on config load Steven Rostedt
@ 2009-02-21  5:58     ` Andrew Morton
  2009-02-21  6:08     ` Andrew Morton
  2009-02-22 16:23     ` [PATCH][RFC] " Ingo Molnar
  2 siblings, 0 replies; 45+ messages in thread
From: Andrew Morton @ 2009-02-21  5:58 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: LKML, linux-kbuild, Randy Dunlap, Frederic Weisbecker,
	Ingo Molnar, zippel, Sam Ravnborg

On Sat, 21 Feb 2009 00:24:05 -0500 (EST) Steven Rostedt <rostedt@goodmis.org> wrote:

> There's been a few problems with SELECT and dependencies lately.
> I've been burnt by it a few times myself. So I look at the kconfig
> code and added this patch. It can use a bit more work but it does what
> I want.
> 
> When the config is loaded, it checks all the symbols that are
> selected by an active config and makes sure the visible dependencies are 
> also activated. This should probably be moved to the writing of the 
> config instead, but since I just wanted to see if my current config was 
> OK, I did it on load. This is an RFC patch anyway, so fixes/comments are 
> definitely welcome.
> 
> Here's what I get with the attached config running on 2.6.29-rc5.
> 
> $ make menuconfig
> scripts/kconfig/mconf arch/x86/Kconfig
> .config:2561:warning: MICROCODE selects FW_LOADER which fails its dependencies!
> .config:2561:warning: MICROCODE_INTEL selects FW_LOADER which fails its dependencies!
> .config:2561:warning: PCMCIA_LOAD_CIS selects FW_LOADER which fails its dependencies!
> .config:2561:warning: SCSI_SAS_LIBSAS selects SCSI_SAS_ATTRS which fails its dependencies!
> .config:2561:warning: SCSI_AIC94XX selects FW_LOADER which fails its dependencies!
> .config:2561:warning: KEYBOARD_ATKBD selects SERIO which fails its dependencies!
> .config:2561:warning: KEYBOARD_ATKBD selects SERIO_LIBPS2 which fails its dependencies!
> .config:2561:warning: KEYBOARD_ATKBD selects SERIO_I8042 which fails its dependencies!
> .config:2561:warning: MOUSE_PS2 selects SERIO which fails its dependencies!
> .config:2561:warning: MOUSE_PS2 selects SERIO_LIBPS2 which fails its dependencies!
> .config:2561:warning: MOUSE_PS2 selects SERIO_I8042 which fails its dependencies!
> .config:2561:warning: VT selects INPUT which fails its dependencies!
> .config:2561:warning: DRM selects I2C_ALGOBIT which fails its dependencies!
> .config:2561:warning: SND_EMU10K1 selects FW_LOADER which fails its dependencies!

Well damn, that looks like a major contribution to the general
well-being.

Sam, could you please give this a scan and merge it into linux-next via
your tree?

I wonder how hard it would be to print out the reason why (for example)
FW_LOADER failed its dependencies?


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

* Re: [PATCH][RFC] check for select dependency errors on config load
  2009-02-21  5:24   ` [PATCH][RFC] check for select dependency errors on config load Steven Rostedt
  2009-02-21  5:58     ` Andrew Morton
@ 2009-02-21  6:08     ` Andrew Morton
  2009-02-21  6:20       ` Randy Dunlap
  2009-02-22 16:23     ` [PATCH][RFC] " Ingo Molnar
  2 siblings, 1 reply; 45+ messages in thread
From: Andrew Morton @ 2009-02-21  6:08 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: LKML, linux-kbuild, Randy Dunlap, Frederic Weisbecker,
	Ingo Molnar, zippel

On Sat, 21 Feb 2009 00:24:05 -0500 (EST) Steven Rostedt <rostedt@goodmis.org> wrote:

> 
> There's been a few problems with SELECT and dependencies lately.
> I've been burnt by it a few times myself. So I look at the kconfig
> code and added this patch. It can use a bit more work but it does what
> I want.
> 
> When the config is loaded, it checks all the symbols that are
> selected by an active config and makes sure the visible dependencies are 
> also activated. This should probably be moved to the writing of the 
> config instead, but since I just wanted to see if my current config was 
> OK, I did it on load. This is an RFC patch anyway, so fixes/comments are 
> definitely welcome.
> 
> Here's what I get with the attached config running on 2.6.29-rc5.
> 
> $ make menuconfig
> scripts/kconfig/mconf arch/x86/Kconfig
> .config:2561:warning: MICROCODE selects FW_LOADER which fails its dependencies!
> .config:2561:warning: MICROCODE_INTEL selects FW_LOADER which fails its dependencies!
> .config:2561:warning: PCMCIA_LOAD_CIS selects FW_LOADER which fails its dependencies!
> .config:2561:warning: SCSI_SAS_LIBSAS selects SCSI_SAS_ATTRS which fails its dependencies!
> .config:2561:warning: SCSI_AIC94XX selects FW_LOADER which fails its dependencies!
> .config:2561:warning: KEYBOARD_ATKBD selects SERIO which fails its dependencies!
> .config:2561:warning: KEYBOARD_ATKBD selects SERIO_LIBPS2 which fails its dependencies!
> .config:2561:warning: KEYBOARD_ATKBD selects SERIO_I8042 which fails its dependencies!
> .config:2561:warning: MOUSE_PS2 selects SERIO which fails its dependencies!
> .config:2561:warning: MOUSE_PS2 selects SERIO_LIBPS2 which fails its dependencies!
> .config:2561:warning: MOUSE_PS2 selects SERIO_I8042 which fails its dependencies!
> .config:2561:warning: VT selects INPUT which fails its dependencies!
> .config:2561:warning: DRM selects I2C_ALGOBIT which fails its dependencies!
> .config:2561:warning: SND_EMU10K1 selects FW_LOADER which fails its dependencies!
> 
> <exit out>
> 

OK, this is fairly easy to use.

You get

.config:1181:warning: PCMCIA_LOAD_CIS selects FW_LOADER which fails its dependencies!

So you then go into `make menuconfig' and type /^fw_loader$ to display
FW_LOADER's dependencies.

	Depends on: HOTPLUG && EMBEDDED

then do `egrep "HOTPLUG|EMBEDDED" .config'

And we discover weird things.  Why does FW_LOADER depend on EMBEDDED?

And why the heck does INPUT depend on EMBEDDED?!??!

And what's up with CONFIG_SERIO?

	Depends on: !S390 && (EMBEDDED || !X86)

hm.

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

* Re: [PATCH][RFC] check for select dependency errors on config load
  2009-02-21  6:08     ` Andrew Morton
@ 2009-02-21  6:20       ` Randy Dunlap
  2009-02-21 20:07         ` Steven Rostedt
  0 siblings, 1 reply; 45+ messages in thread
From: Randy Dunlap @ 2009-02-21  6:20 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Steven Rostedt, LKML, linux-kbuild, Randy Dunlap,
	Frederic Weisbecker, Ingo Molnar, zippel

Andrew Morton wrote:
> On Sat, 21 Feb 2009 00:24:05 -0500 (EST) Steven Rostedt <rostedt@goodmis.org> wrote:
> 
>> There's been a few problems with SELECT and dependencies lately.
>> I've been burnt by it a few times myself. So I look at the kconfig
>> code and added this patch. It can use a bit more work but it does what
>> I want.
>>
>> When the config is loaded, it checks all the symbols that are
>> selected by an active config and makes sure the visible dependencies are 
>> also activated. This should probably be moved to the writing of the 
>> config instead, but since I just wanted to see if my current config was 
>> OK, I did it on load. This is an RFC patch anyway, so fixes/comments are 
>> definitely welcome.
>>
>> Here's what I get with the attached config running on 2.6.29-rc5.
>>
>> $ make menuconfig
>> scripts/kconfig/mconf arch/x86/Kconfig
>> .config:2561:warning: MICROCODE selects FW_LOADER which fails its dependencies!
>> .config:2561:warning: MICROCODE_INTEL selects FW_LOADER which fails its dependencies!
>> .config:2561:warning: PCMCIA_LOAD_CIS selects FW_LOADER which fails its dependencies!
>> .config:2561:warning: SCSI_SAS_LIBSAS selects SCSI_SAS_ATTRS which fails its dependencies!
>> .config:2561:warning: SCSI_AIC94XX selects FW_LOADER which fails its dependencies!
>> .config:2561:warning: KEYBOARD_ATKBD selects SERIO which fails its dependencies!
>> .config:2561:warning: KEYBOARD_ATKBD selects SERIO_LIBPS2 which fails its dependencies!
>> .config:2561:warning: KEYBOARD_ATKBD selects SERIO_I8042 which fails its dependencies!
>> .config:2561:warning: MOUSE_PS2 selects SERIO which fails its dependencies!
>> .config:2561:warning: MOUSE_PS2 selects SERIO_LIBPS2 which fails its dependencies!
>> .config:2561:warning: MOUSE_PS2 selects SERIO_I8042 which fails its dependencies!
>> .config:2561:warning: VT selects INPUT which fails its dependencies!
>> .config:2561:warning: DRM selects I2C_ALGOBIT which fails its dependencies!
>> .config:2561:warning: SND_EMU10K1 selects FW_LOADER which fails its dependencies!
>>
>> <exit out>
>>
> 
> OK, this is fairly easy to use.
> 
> You get
> 
> .config:1181:warning: PCMCIA_LOAD_CIS selects FW_LOADER which fails its dependencies!
> 
> So you then go into `make menuconfig' and type /^fw_loader$ to display
> FW_LOADER's dependencies.
> 
> 	Depends on: HOTPLUG && EMBEDDED
> 
> then do `egrep "HOTPLUG|EMBEDDED" .config'
> 
> And we discover weird things.  Why does FW_LOADER depend on EMBEDDED?
> 
> And why the heck does INPUT depend on EMBEDDED?!??!
> 
> And what's up with CONFIG_SERIO?
> 
> 	Depends on: !S390 && (EMBEDDED || !X86)
> 
> hm.

EMBEDDED is misnamed.  It means "those who think that they know enough
to use all of the power of kconfig."
Some people spell that EXPERT etc.
Or it means "let me shoot myself in the foot."

So HOTPLUG, INPUT, FW_LOADER, etc. should not be modified by Aunt Tillie,
but you and I can play with them.


for SERIO:

config SERIO
	tristate "Serial I/O support" if EMBEDDED || !X86
	default y

Experts can modify it.  !X86 can modify it.
It's usually needed on X86 for keyboard controllers etc.,
but if one sets EMBEDDED, you can muck up your config and not be
able to use the keyboard.

I don't know where the !S390 comes from, but it's not surprising.

-- 
~Randy

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

* Re: [PATCH][RFC] check for select dependency errors on config load
  2009-02-21  6:20       ` Randy Dunlap
@ 2009-02-21 20:07         ` Steven Rostedt
  2009-02-21 20:46           ` [PATCH v2] kconfig: " Steven Rostedt
  0 siblings, 1 reply; 45+ messages in thread
From: Steven Rostedt @ 2009-02-21 20:07 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Andrew Morton, LKML, linux-kbuild, Frederic Weisbecker,
	Ingo Molnar, zippel


On Fri, 20 Feb 2009, Randy Dunlap wrote:
> 
> EMBEDDED is misnamed.  It means "those who think that they know enough
> to use all of the power of kconfig."
> Some people spell that EXPERT etc.
> Or it means "let me shoot myself in the foot."
> 
> So HOTPLUG, INPUT, FW_LOADER, etc. should not be modified by Aunt Tillie,
> but you and I can play with them.

We really should go and rename it then :-/

> 
> 
> for SERIO:
> 
> config SERIO
> 	tristate "Serial I/O support" if EMBEDDED || !X86
> 	default y
> 
> Experts can modify it.  !X86 can modify it.
> It's usually needed on X86 for keyboard controllers etc.,
> but if one sets EMBEDDED, you can muck up your config and not be
> able to use the keyboard.
> 
> I don't know where the !S390 comes from, but it's not surprising.

Anyway, to avoid having these spit out all the time, I'll see if I can 
make it not warn if the dependency was on EMBEDDED/EXPERT. I'll try to 
work on it when I have time.

Note, the config I used was originally generated by randconfig.

Thanks,

-- Steve


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

* [PATCH v2] kconfig: check for select dependency errors on config load
  2009-02-21 20:07         ` Steven Rostedt
@ 2009-02-21 20:46           ` Steven Rostedt
  2009-02-21 20:48             ` Steven Rostedt
  2009-02-21 21:51             ` Sam Ravnborg
  0 siblings, 2 replies; 45+ messages in thread
From: Steven Rostedt @ 2009-02-21 20:46 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Andrew Morton, LKML, linux-kbuild, Frederic Weisbecker,
	Ingo Molnar, zippel


On Sat, 21 Feb 2009, Steven Rostedt wrote:
> On Fri, 20 Feb 2009, Randy Dunlap wrote:
> > EMBEDDED is misnamed.  It means "those who think that they know enough
> > to use all of the power of kconfig."
> > Some people spell that EXPERT etc.
> > Or it means "let me shoot myself in the foot."

> 
> Anyway, to avoid having these spit out all the time, I'll see if I can 
> make it not warn if the dependency was on EMBEDDED/EXPERT. I'll try to 
> work on it when I have time.

That was easier than I expected. Here's an updated version of the patch.

It now finds the symbol EMBEDDED, saves its state. Updates its state to 
'yes', runs the tests, resets its state back to what it was.

Now all I get from that previous config:

$ make menuconfig
scripts/kconfig/mconf arch/x86/Kconfig
.config:2561:warning: SCSI_SAS_LIBSAS selects SCSI_SAS_ATTRS which fails its dependencies!
.config:2561:warning: DRM selects I2C_ALGOBIT which fails its dependencies!

Hmm, that I2C_ALGOBIT depends on I2C_HELPER_AUTO, which looks similar to 
the EMBEDDED option. That is, Don't show this option unless this is not 
selected. I may just add a 'WHITELIST' of things that will be enabled 
during thet test.

But the SCSI_SAS_ATTRS depends on BLK_DEV_BSG which is not selected.


I also added to run the test on write as well.

But having it find the culprits will require a bit more that 5 minutes of
work. That will stay on my TODO list for now.

Signed-off-by: Steven Rostedt <srostedt@redhat.com>

diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 830d9ea..7717926 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -310,6 +310,127 @@ load:
 	return 0;
 }
 
+static int test_deps(struct symbol *sym)
+{
+	struct property *prop;
+	struct expr *expr;
+
+	if (sym->rev_dep.tri == no)
+		return 1;
+
+	for (prop = sym->prop; prop; prop = prop->next) {
+		if (prop->type != P_PROMPT)
+			continue;
+
+		expr = prop->visible.expr;
+		if (!expr)
+			continue;
+
+		if (expr_calc_value(expr) == no)
+			return 0;
+	}
+
+	return 1;
+}
+
+void test_select(struct symbol *sym)
+{
+	struct property *prop;
+	struct expr *expr;
+
+	for (prop = sym->prop; prop; prop = prop->next) {
+		if (prop->type != P_SELECT)
+			continue;
+
+		expr = prop->expr;
+
+		if (!expr || expr->type != E_SYMBOL ||
+		    !expr->left.sym)
+			continue;
+			
+		if (test_deps(expr->left.sym))
+			continue;
+
+		conf_warning("%s selects %s which fails its dependencies!",
+			     sym->name, expr->left.sym->name);
+	}
+}
+
+void test_conf(void)
+{
+	struct symbol *sym, *embedded;
+	tristate embed_tri;
+	struct menu *menu;
+	int type;
+
+	/*
+	 * EMBEDDED is more like an "EXPERT" option. It is OK
+	 * to select it even when it does not have the proper
+	 * dependencies.
+	 *
+	 * Find  the EMBEDDED symbol.
+	 * Save its state.
+	 * Set it to 'yes'.
+	 * Run tests.
+	 * Reset the EMBEDDED symbol.
+	 */
+	embedded = sym_lookup("EMBEDDED", 0);
+	embed_tri = embedded->curr.tri;
+	embedded->curr.tri = yes;
+	
+	menu = rootmenu.list;
+	while (menu) {
+		sym = menu->sym;
+		if (!sym)
+			goto next;
+
+		if (!(sym->flags & SYMBOL_CHOICE)) {
+			sym_calc_value(sym);
+			if (!(sym->flags & SYMBOL_WRITE))
+				goto next;
+			type = sym->type;
+			if (type == S_TRISTATE) {
+				sym_calc_value(modules_sym);
+				if (modules_sym->curr.tri == no)
+					type = S_BOOLEAN;
+			}
+			switch (type) {
+			case S_BOOLEAN:
+			case S_TRISTATE:
+				switch (sym_get_tristate_value(sym)) {
+				case no:
+					break;
+				case mod:
+				case yes:
+					test_select(sym);
+					break;
+				}
+				break;
+			case S_STRING:
+			case S_HEX:
+			case S_INT:
+				break;
+			}
+		}
+
+	next:
+		if (menu->list) {
+			menu = menu->list;
+			continue;
+		}
+		if (menu->next)
+			menu = menu->next;
+		else while ((menu = menu->parent)) {
+			if (menu->next) {
+				menu = menu->next;
+				break;
+			}
+		}
+	}
+
+	embedded->curr.tri = embed_tri;
+}
+
 int conf_read(const char *name)
 {
 	struct symbol *sym, *choice_sym;
@@ -386,6 +507,7 @@ int conf_read(const char *name)
 
 	sym_add_change_count(conf_warnings || conf_unsaved);
 
+	test_conf();
 	return 0;
 }
 
@@ -550,6 +672,8 @@ int conf_write(const char *name)
 
 	sym_set_change_count(0);
 
+	test_conf();
+
 	return 0;
 }
 


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

* Re: [PATCH v2] kconfig: check for select dependency errors on config load
  2009-02-21 20:46           ` [PATCH v2] kconfig: " Steven Rostedt
@ 2009-02-21 20:48             ` Steven Rostedt
  2009-02-21 21:51             ` Sam Ravnborg
  1 sibling, 0 replies; 45+ messages in thread
From: Steven Rostedt @ 2009-02-21 20:48 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Andrew Morton, LKML, linux-kbuild, Frederic Weisbecker,
	Ingo Molnar, zippel


On Sat, 21 Feb 2009, Steven Rostedt wrote:
> 
> Hmm, that I2C_ALGOBIT depends on I2C_HELPER_AUTO, which looks similar to 
> the EMBEDDED option. That is, Don't show this option unless this is not 
> selected. I may just add a 'WHITELIST' of things that will be enabled 
> during thet test.

It is actually the opposite of EMBEDDED. It is, show this item if 
I2C_HELPER_AUTO is _not_ selected.

-- Steve


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

* Re: [PATCH v2] kconfig: check for select dependency errors on config load
  2009-02-21 20:46           ` [PATCH v2] kconfig: " Steven Rostedt
  2009-02-21 20:48             ` Steven Rostedt
@ 2009-02-21 21:51             ` Sam Ravnborg
  2009-02-21 21:53               ` Steven Rostedt
  1 sibling, 1 reply; 45+ messages in thread
From: Sam Ravnborg @ 2009-02-21 21:51 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Randy Dunlap, Andrew Morton, LKML, linux-kbuild,
	Frederic Weisbecker, Ingo Molnar, zippel

On Sat, Feb 21, 2009 at 03:46:29PM -0500, Steven Rostedt wrote:
> 
> On Sat, 21 Feb 2009, Steven Rostedt wrote:
> > On Fri, 20 Feb 2009, Randy Dunlap wrote:
> > > EMBEDDED is misnamed.  It means "those who think that they know enough
> > > to use all of the power of kconfig."
> > > Some people spell that EXPERT etc.
> > > Or it means "let me shoot myself in the foot."
> 
> > 
> > Anyway, to avoid having these spit out all the time, I'll see if I can 
> > make it not warn if the dependency was on EMBEDDED/EXPERT. I'll try to 
> > work on it when I have time.
> 
> That was easier than I expected. Here's an updated version of the patch.
> 
> It now finds the symbol EMBEDDED, saves its state. Updates its state to 
> 'yes', runs the tests, resets its state back to what it was.

We do not want to have such hardcoded information
about the Kconfig structure in the backend.
Rather we should fix the configuration once and for all so EMBEDDED
get split into the sensible options is actually is.

Options that come to my mind is:
OPTIMIZE_FOR_TEXT_SIZE
OPTIMIZE_FOR_DATA_SIZE
KERNEL_EXPERT

And we should them make their use of select conform
like the rest of the kernel configuration.

So the first version of your patch is IMO better - but
it could use some comments so others better follows what is
going on. The current level of comments in the kconfig
source base is not an example to follw

	Sam

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

* Re: [PATCH v2] kconfig: check for select dependency errors on config load
  2009-02-21 21:51             ` Sam Ravnborg
@ 2009-02-21 21:53               ` Steven Rostedt
  0 siblings, 0 replies; 45+ messages in thread
From: Steven Rostedt @ 2009-02-21 21:53 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: Randy Dunlap, Andrew Morton, LKML, linux-kbuild,
	Frederic Weisbecker, Ingo Molnar, zippel


On Sat, 21 Feb 2009, Sam Ravnborg wrote:
> 
> We do not want to have such hardcoded information
> about the Kconfig structure in the backend.
> Rather we should fix the configuration once and for all so EMBEDDED
> get split into the sensible options is actually is.
> 
> Options that come to my mind is:
> OPTIMIZE_FOR_TEXT_SIZE
> OPTIMIZE_FOR_DATA_SIZE
> KERNEL_EXPERT
> 
> And we should them make their use of select conform
> like the rest of the kernel configuration.
> 
> So the first version of your patch is IMO better - but
> it could use some comments so others better follows what is
> going on. The current level of comments in the kconfig
> source base is not an example to follw

Sounds good. Yeah, the first patch was an RFC mainly because I want 
someone to look at the code and tell me "yeah that works" or "No! you 
can't do that". Because I spent several hours staring at the kconfig code 
trying to figure out WTF it was doing. Luckily, I did have a compiler 
writing course and the flex and bison code was fine for me.

I will definitely update the code with comments when I'm more comfortable 
with the code.

-- Steve


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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-20 17:48       ` Ingo Molnar
  2009-02-20 18:56         ` Jason Baron
  2009-02-21  3:15         ` Frederic Weisbecker
@ 2009-02-21 22:04         ` Frank Ch. Eigler
  2009-02-22 17:13           ` Ingo Molnar
  2009-02-23 10:13         ` Avi Kivity
  3 siblings, 1 reply; 45+ messages in thread
From: Frank Ch. Eigler @ 2009-02-21 22:04 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Frederic Weisbecker, Avi Kivity, Randy Dunlap, Steven Rostedt,
	linux-kernel, linux-kbuild

Ingo Molnar <mingo@elte.hu> writes:

> [...]
> there's i think the KVM usecase where markers are used 
> essentially a printk()-alike flexible tracing facility.
>
> [...]
> ./vmx.c:	KVMTRACE_3D(MSR_READ, vcpu, ecx, (u32)data, (u32)(data >> 32),
> ./vmx.c:	KVMTRACE_3D(MSR_WRITE, vcpu, ecx, (u32)data, (u32)(data >> 32),
> ./vmx.c:	KVMTRACE_0D(PEND_INTR, vcpu, handler);
>
> I think this could easily be converted to a wrapper around 
> ftrace_printk() plus a "kvmtrace" ftrace plugin [...]

It would be even easier converted to the markers API directly,
without the KVMTRACE* macro intermediary:

before:
        KVMTRACE_3D(MSR_READ, &svm->vcpu, ecx, (u32)data,
                    (u32)(data >> 32), handler);
after:
	trace_mark(kvmtrace, "MSR_READ: %p, %08lx, %016Lx\n",
                             &svm->vcpu, ecx, data);

All this already "just works".

The only part that's missing, from ftrace's point of view, is an
interface from markers to the ftrace printing.  And Lai Jiangshan
kindly posted exactly such generic code back in December:

http://lkml.org/lkml/2008/12/30/297

Please let's get this merged.

> This means KVM tracing is activated via:
>  echo kvmtrace > /debug/tracing/current_tracer
> that's all.

Lai's interface is almost identical, and automatically works for
any/all markers.


> And any ad-hoc tracepoint can be added, without worrying about 
> the name of the macro or the number of type of arguments. [...]

(This KVMTRACE stuff was always unnecessary with respect to markers,
and must have been explained by some historical baggage.)


- FChE

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-20 17:22   ` Ingo Molnar
  2009-02-20 17:29     ` Randy Dunlap
  2009-02-20 17:31     ` Frederic Weisbecker
@ 2009-02-22  3:23     ` KOSAKI Motohiro
  2009-02-22 11:37       ` Peter Zijlstra
  2009-02-22 11:43     ` Peter Zijlstra
  3 siblings, 1 reply; 45+ messages in thread
From: KOSAKI Motohiro @ 2009-02-22  3:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: kosaki.motohiro, Randy Dunlap, Frederic Weisbecker,
	Steven Rostedt, linux-kernel, zippel, linux-kbuild,
	Frank Ch. Eigler, Mathieu Desnoyers

Hi

(cc to Frank and Mathieu)

> > >  config MARKERS
> > >  	bool "Activate markers"
> > > -	depends on TRACEPOINTS
> > > +	select TRACEPOINTS
> > >  	help
> > >  	  Place an empty function call at each marker site. Can be
> > >  	  dynamically changed for a probe function.
> > 
> > but using "select" instead of "depends on" just causes the 
> > kind of problem that you described, whereas using "depends on" 
> > does follow dependency chains.
> 
> Well, as long as the secondary selects are 'expanded' along the 
> line of dependencies, it should still be fine. With an 
> increasing number of dependencies it quickly becomes ugly 
> though. This might be one of the cases where it works.
> 
> Eventually we should eliminate markers, their uses can either be 
> converted to new-style tracepoints, or to ftrace_printk().

IIRC, this suggestion still don't get agreement of all tracing feature stakeholder.
We need to definitely discuss more lot and deep.
so I wonder why don't we create linux-tracing new mailing list.

tracer feature perfectly have new ML creation condition
  - very active development
  - many stakeholder and developer
  - use many common parts (eg, marker, kprobe, unified buffer)





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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-22  3:23     ` KOSAKI Motohiro
@ 2009-02-22 11:37       ` Peter Zijlstra
  2009-02-22 16:04         ` Mathieu Desnoyers
  0 siblings, 1 reply; 45+ messages in thread
From: Peter Zijlstra @ 2009-02-22 11:37 UTC (permalink / raw)
  To: KOSAKI Motohiro
  Cc: Ingo Molnar, Randy Dunlap, Frederic Weisbecker, Steven Rostedt,
	linux-kernel, zippel, linux-kbuild, Frank Ch. Eigler,
	Mathieu Desnoyers

On Sun, 2009-02-22 at 12:23 +0900, KOSAKI Motohiro wrote:

> IIRC, this suggestion still don't get agreement of all tracing feature stakeholder.
> We need to definitely discuss more lot and deep.
> so I wonder why don't we create linux-tracing new mailing list.

Yes, lets hide it from general view, sounds like a brilliant plan.




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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-20 17:22   ` Ingo Molnar
                       ` (2 preceding siblings ...)
  2009-02-22  3:23     ` KOSAKI Motohiro
@ 2009-02-22 11:43     ` Peter Zijlstra
  2009-02-22 12:08       ` Frank Ch. Eigler
  2009-02-23  0:23       ` Steven Rostedt
  3 siblings, 2 replies; 45+ messages in thread
From: Peter Zijlstra @ 2009-02-22 11:43 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Randy Dunlap, Frederic Weisbecker, Steven Rostedt, linux-kernel,
	zippel, linux-kbuild

On Fri, 2009-02-20 at 18:22 +0100, Ingo Molnar wrote:
> Eventually we should eliminate markers, their uses can either be 
> converted to new-style tracepoints, or to ftrace_printk().

I would like to never merge an ftrace_printk() user... just as I'd like
to get rid of every marker.

Then again, some people appear happy to commit their printk debug spree
too :/


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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-22 11:43     ` Peter Zijlstra
@ 2009-02-22 12:08       ` Frank Ch. Eigler
  2009-02-22 12:14         ` Peter Zijlstra
  2009-02-23  0:23       ` Steven Rostedt
  1 sibling, 1 reply; 45+ messages in thread
From: Frank Ch. Eigler @ 2009-02-22 12:08 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Randy Dunlap, Frederic Weisbecker, Steven Rostedt,
	linux-kernel, zippel, linux-kbuild

Peter Zijlstra <peterz@infradead.org> writes:

> I would like to never merge an ftrace_printk() user... just as I'd like
> to get rid of every marker.

But why?  They solve a problem well enough that Ingo had in effect
reinvented them on Friday.

- FChE

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-22 12:08       ` Frank Ch. Eigler
@ 2009-02-22 12:14         ` Peter Zijlstra
  2009-02-22 12:24           ` Frank Ch. Eigler
  0 siblings, 1 reply; 45+ messages in thread
From: Peter Zijlstra @ 2009-02-22 12:14 UTC (permalink / raw)
  To: Frank Ch. Eigler
  Cc: Ingo Molnar, Randy Dunlap, Frederic Weisbecker, Steven Rostedt,
	linux-kernel, zippel, linux-kbuild

On Sun, 2009-02-22 at 07:08 -0500, Frank Ch. Eigler wrote:
> Peter Zijlstra <peterz@infradead.org> writes:
> 
> > I would like to never merge an ftrace_printk() user... just as I'd like
> > to get rid of every marker.
> 
> But why?  They solve a problem well enough that Ingo had in effect
> reinvented them on Friday.

Because after a printk() debug spree, I don't commit them, I toss them
out and keep the fix.


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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-22 12:14         ` Peter Zijlstra
@ 2009-02-22 12:24           ` Frank Ch. Eigler
  2009-02-23 11:11             ` Peter Zijlstra
  0 siblings, 1 reply; 45+ messages in thread
From: Frank Ch. Eigler @ 2009-02-22 12:24 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Randy Dunlap, Frederic Weisbecker, Steven Rostedt,
	linux-kernel, zippel, linux-kbuild

Hi -

On Sun, Feb 22, 2009 at 01:14:36PM +0100, Peter Zijlstra wrote:
> > > I would like to never merge an ftrace_printk() user... just as I'd like
> > > to get rid of every marker.
> > 
> > But why?  They solve a problem well enough that Ingo had in effect
> > reinvented them on Friday.
> 
> Because after a printk() debug spree, I don't commit them, I toss them
> out and keep the fix.

Markers solve a problem closer to tracepoints than to debugging
printk's.

In this context, the main difference between tracepoints is that
markers need almost no hand-written glue code of the sort that make up
ftrace engines that just trace simple values.  Simpler & smaller code
for the same output seems like a win.

- FChE

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-22 11:37       ` Peter Zijlstra
@ 2009-02-22 16:04         ` Mathieu Desnoyers
  2009-02-22 19:17           ` Ingo Molnar
  0 siblings, 1 reply; 45+ messages in thread
From: Mathieu Desnoyers @ 2009-02-22 16:04 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: KOSAKI Motohiro, Ingo Molnar, Randy Dunlap, Frederic Weisbecker,
	Steven Rostedt, linux-kernel, zippel, linux-kbuild,
	Frank Ch. Eigler

* Peter Zijlstra (peterz@infradead.org) wrote:
> On Sun, 2009-02-22 at 12:23 +0900, KOSAKI Motohiro wrote:
> 
> > IIRC, this suggestion still don't get agreement of all tracing feature stakeholder.
> > We need to definitely discuss more lot and deep.
> > so I wonder why don't we create linux-tracing new mailing list.
> 
> Yes, lets hide it from general view, sounds like a brilliant plan.
> 
> 
> 

I guess Kosaki's point is that there may be a disconnect between the
work that is done on the LTTng side and the ftrace side. LTTng uses the
markers as a core infrastructure part (and tracepoints for
instrumentation). I guess his idea is to improve communication, not to
stop it. So by your reaction, I guess his proposal might not be ideal,
but I hear his concerns. I'll try to post the core lttng patchset
shortly.

Mathieu


-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

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

* Re: [PATCH][RFC] check for select dependency errors on config load
  2009-02-21  5:24   ` [PATCH][RFC] check for select dependency errors on config load Steven Rostedt
  2009-02-21  5:58     ` Andrew Morton
  2009-02-21  6:08     ` Andrew Morton
@ 2009-02-22 16:23     ` Ingo Molnar
  2 siblings, 0 replies; 45+ messages in thread
From: Ingo Molnar @ 2009-02-22 16:23 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: LKML, linux-kbuild, Randy Dunlap, Frederic Weisbecker, zippel,
	Andrew Morton


* Steven Rostedt <rostedt@goodmis.org> wrote:

> There's been a few problems with SELECT and dependencies 
> lately. I've been burnt by it a few times myself. So I look at 
> the kconfig code and added this patch. It can use a bit more 
> work but it does what I want.
> 
> When the config is loaded, it checks all the symbols that are 
> selected by an active config and makes sure the visible 
> dependencies are also activated. This should probably be moved 
> to the writing of the config instead, but since I just wanted 
> to see if my current config was OK, I did it on load. This is 
> an RFC patch anyway, so fixes/comments are definitely welcome.
> 
> Here's what I get with the attached config running on 
> 2.6.29-rc5.

Yah! Very nice Steve.

/me nominates Steve as the Kconfig maintainer :-)

	Ingo

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-21 22:04         ` Frank Ch. Eigler
@ 2009-02-22 17:13           ` Ingo Molnar
  2009-02-22 17:38             ` Frank Ch. Eigler
  0 siblings, 1 reply; 45+ messages in thread
From: Ingo Molnar @ 2009-02-22 17:13 UTC (permalink / raw)
  To: Frank Ch. Eigler
  Cc: Frederic Weisbecker, Avi Kivity, Randy Dunlap, Steven Rostedt,
	linux-kernel, linux-kbuild


* Frank Ch. Eigler <fche@redhat.com> wrote:

> Ingo Molnar <mingo@elte.hu> writes:
> 
> > [...]
> > there's i think the KVM usecase where markers are used 
> > essentially a printk()-alike flexible tracing facility.
> >
> > [...]
> > ./vmx.c:	KVMTRACE_3D(MSR_READ, vcpu, ecx, (u32)data, (u32)(data >> 32),
> > ./vmx.c:	KVMTRACE_3D(MSR_WRITE, vcpu, ecx, (u32)data, (u32)(data >> 32),
> > ./vmx.c:	KVMTRACE_0D(PEND_INTR, vcpu, handler);
> >
> > I think this could easily be converted to a wrapper around 
> > ftrace_printk() plus a "kvmtrace" ftrace plugin [...]
> 
> It would be even easier converted to the markers API directly,
> without the KVMTRACE* macro intermediary:
> 
> before:
>         KVMTRACE_3D(MSR_READ, &svm->vcpu, ecx, (u32)data,
>                     (u32)(data >> 32), handler);
> after:
> 	trace_mark(kvmtrace, "MSR_READ: %p, %08lx, %016Lx\n",
>                              &svm->vcpu, ecx, data);
> 
> All this already "just works".

except that we are removing markers.

	Ingo

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-22 17:13           ` Ingo Molnar
@ 2009-02-22 17:38             ` Frank Ch. Eigler
  0 siblings, 0 replies; 45+ messages in thread
From: Frank Ch. Eigler @ 2009-02-22 17:38 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Frederic Weisbecker, Avi Kivity, Randy Dunlap, Steven Rostedt,
	linux-kernel, linux-kbuild

Hi -

On Sun, Feb 22, 2009 at 06:13:44PM +0100, Ingo Molnar wrote:
> [...]
> > It would be even easier converted to the markers API directly,
> > without the KVMTRACE* macro intermediary:
> > 
> > before:
> >         KVMTRACE_3D(MSR_READ, &svm->vcpu, ecx, (u32)data,
> >                     (u32)(data >> 32), handler);
> > after:
> > 	trace_mark(kvmtrace, "MSR_READ: %p, %08lx, %016Lx\n",
> >                              &svm->vcpu, ecx, data);
> > 
> > All this already "just works".
> except that we are removing markers.

Perhaps that intention should be justified and reexamined, especially
considering the KVMTRACE* macro-replacement solution you suggested is
almost the same.


- FChE

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-22 16:04         ` Mathieu Desnoyers
@ 2009-02-22 19:17           ` Ingo Molnar
  2009-02-23  2:47             ` Mathieu Desnoyers
  0 siblings, 1 reply; 45+ messages in thread
From: Ingo Molnar @ 2009-02-22 19:17 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Peter Zijlstra, KOSAKI Motohiro, Randy Dunlap,
	Frederic Weisbecker, Steven Rostedt, linux-kernel,
	Frank Ch. Eigler, Thomas Gleixner


* Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:

> > > so I wonder why don't we create linux-tracing new mailing 
> > > list.

Discussions related to upstream Linux tracing are generally 
conducted on lkml.

> > Yes, lets hide it from general view, sounds like a brilliant 
> > plan.
> 
> I guess Kosaki's point is that there may be a disconnect 
> between the work that is done on the LTTng side and the ftrace 
> side. [...]

Could you please list the items we need to extend the tracing 
framework in kernel/tracing/* with so that we can support the 
aspects of LTTng you consider important and upstream-worthy?

As i've mentioned it in the past, i'm definitely interested in 
helping such an effort to further improve Linux tracing.

	Ingo

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-22 11:43     ` Peter Zijlstra
  2009-02-22 12:08       ` Frank Ch. Eigler
@ 2009-02-23  0:23       ` Steven Rostedt
  1 sibling, 0 replies; 45+ messages in thread
From: Steven Rostedt @ 2009-02-23  0:23 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Randy Dunlap, Frederic Weisbecker, linux-kernel,
	zippel, linux-kbuild


On Sun, 22 Feb 2009, Peter Zijlstra wrote:

> On Fri, 2009-02-20 at 18:22 +0100, Ingo Molnar wrote:
> > Eventually we should eliminate markers, their uses can either be 
> > converted to new-style tracepoints, or to ftrace_printk().
> 
> I would like to never merge an ftrace_printk() user... just as I'd like
> to get rid of every marker.
> 
> Then again, some people appear happy to commit their printk debug spree
> too :/

/me looks at arch/powerpc/kernel/ftrace.c and realizes that he's guilty as 
charged :-p

-- Steve


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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-22 19:17           ` Ingo Molnar
@ 2009-02-23  2:47             ` Mathieu Desnoyers
  2009-02-23  8:52               ` Ingo Molnar
  0 siblings, 1 reply; 45+ messages in thread
From: Mathieu Desnoyers @ 2009-02-23  2:47 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Peter Zijlstra, KOSAKI Motohiro, Randy Dunlap,
	Frederic Weisbecker, Steven Rostedt, linux-kernel,
	Frank Ch. Eigler, Thomas Gleixner

* Ingo Molnar (mingo@elte.hu) wrote:
> 
> * Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> 
> > > > so I wonder why don't we create linux-tracing new mailing 
> > > > list.
> 
> Discussions related to upstream Linux tracing are generally 
> conducted on lkml.
> 
> > > Yes, lets hide it from general view, sounds like a brilliant 
> > > plan.
> > 
> > I guess Kosaki's point is that there may be a disconnect 
> > between the work that is done on the LTTng side and the ftrace 
> > side. [...]
> 
> Could you please list the items we need to extend the tracing 
> framework in kernel/tracing/* with so that we can support the 
> aspects of LTTng you consider important and upstream-worthy?
> 
> As i've mentioned it in the past, i'm definitely interested in 
> helping such an effort to further improve Linux tracing.
> 
> 	Ingo

Hi Ingo,

I have not merged the "binary trace buffer to ascii" code done by
Fujitsu yet because I still have to review it, but when it's ready, I
will be ready to post everything that has been identified as wish list
for a tracer v2. It includes a very generic buffering infrastructure
which have been evolving for the past 4 years (and reviewed on LKML a
couple of times in the past).

So, either I start to merge this last feature, or I can start posting
right away without the "binary buffer to ascii" module. The standard
mechanism used in LTTng is binary-only, very high speed, and uses a
userspace application to transform binary data into text.

That will let us figure out what overlaps between ftrace and LTTng and
find out how those two can fit together.

Note that for the moment, LTTng sits in the /ltt directory of the kernel
tree, so even if we have both tracers at some point, we should not step
on each other's foot. That could let us room to figure out how to
incrementally combine those tracers if that makes sense.

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-23  2:47             ` Mathieu Desnoyers
@ 2009-02-23  8:52               ` Ingo Molnar
  0 siblings, 0 replies; 45+ messages in thread
From: Ingo Molnar @ 2009-02-23  8:52 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Peter Zijlstra, KOSAKI Motohiro, Randy Dunlap,
	Frederic Weisbecker, Steven Rostedt, linux-kernel,
	Frank Ch. Eigler, Thomas Gleixner


* Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:

> * Ingo Molnar (mingo@elte.hu) wrote:
> > 
> > * Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> > 
> > > > > so I wonder why don't we create linux-tracing new mailing 
> > > > > list.
> > 
> > Discussions related to upstream Linux tracing are generally 
> > conducted on lkml.
> > 
> > > > Yes, lets hide it from general view, sounds like a brilliant 
> > > > plan.
> > > 
> > > I guess Kosaki's point is that there may be a disconnect 
> > > between the work that is done on the LTTng side and the ftrace 
> > > side. [...]
> > 
> > Could you please list the items we need to extend the tracing 
> > framework in kernel/tracing/* with so that we can support the 
> > aspects of LTTng you consider important and upstream-worthy?
> > 
> > As i've mentioned it in the past, i'm definitely interested in 
> > helping such an effort to further improve Linux tracing.
> > 
> > 	Ingo
> 
> Hi Ingo,
> 
> I have not merged the "binary trace buffer to ascii" code done 
> by Fujitsu yet because I still have to review it, but when 
> it's ready, I will be ready to post everything that has been 
> identified as wish list for a tracer v2. It includes a very 
> generic buffering infrastructure which have been evolving for 
> the past 4 years (and reviewed on LKML a couple of times in 
> the past).
> 
> So, either I start to merge this last feature, or I can start 
> posting right away without the "binary buffer to ascii" 
> module. The standard mechanism used in LTTng is binary-only, 
> very high speed, and uses a userspace application to transform 
> binary data into text.
> 
> That will let us figure out what overlaps between ftrace and 
> LTTng and find out how those two can fit together.
> 
> Note that for the moment, LTTng sits in the /ltt directory of 
> the kernel tree, so even if we have both tracers at some 
> point, we should not step on each other's foot. That could let 
> us room to figure out how to incrementally combine those 
> tracers if that makes sense.

I think you got me wrong Mathieu. The way to combine those two 
tracers is to do it _before_ it gets merged upstream. We 
obviously dont want to parallel tracing frameworks in the 
upstream kernel.

So ... please lets work on that, okay?

	Ingo

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-20 17:48       ` Ingo Molnar
                           ` (2 preceding siblings ...)
  2009-02-21 22:04         ` Frank Ch. Eigler
@ 2009-02-23 10:13         ` Avi Kivity
  3 siblings, 0 replies; 45+ messages in thread
From: Avi Kivity @ 2009-02-23 10:13 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Frederic Weisbecker, Randy Dunlap, Steven Rostedt, linux-kernel,
	linux-kbuild

Ingo Molnar wrote:
>         KVMTRACE_3D(MSR_READ, &svm->vcpu, ecx, (u32)data,
>                     (u32)(data >> 32), handler);
>
> after:
>
> 	kvm_trace("MSR_READ: %p, %08lx, %016Lx\n", &svm->vcpu, ecx, data);
>
> As a result all these traces would become a lot more readable 
> (and a lot more flexible) both in the source code, and in the 
> trace output stage.
>
> And any ad-hoc tracepoint can be added, without worrying about 
> the name of the macro or the number of type of arguments. Note 
> that in this specific example we didnt need to split up the u64 
> 'data' into two 32-bit values, nor do we have to pass in the 
> 'handler' name, nor do we have to provide a MSR_READ 
> enumeration.
>
> The tracing-disabled case would still be as fast - a single 
> branch check.
>
> Avi, what do you think, any objections against an RFC patchset 
> that shows this off?
>
>   

Definitely, as long as formatting is performed after the data is 
gathered (say, in userspace).  kvmtrace can generate around 1M 
events/sec/cpu, so we need truly low overhead.

-- 
error compiling committee.c: too many arguments to function


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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-22 12:24           ` Frank Ch. Eigler
@ 2009-02-23 11:11             ` Peter Zijlstra
  2009-02-23 15:44               ` Frank Ch. Eigler
  0 siblings, 1 reply; 45+ messages in thread
From: Peter Zijlstra @ 2009-02-23 11:11 UTC (permalink / raw)
  To: Frank Ch. Eigler
  Cc: Ingo Molnar, Randy Dunlap, Frederic Weisbecker, Steven Rostedt,
	linux-kernel, zippel, linux-kbuild

On Sun, 2009-02-22 at 07:24 -0500, Frank Ch. Eigler wrote:
> Hi -
> 
> On Sun, Feb 22, 2009 at 01:14:36PM +0100, Peter Zijlstra wrote:
> > > > I would like to never merge an ftrace_printk() user... just as I'd like
> > > > to get rid of every marker.
> > > 
> > > But why?  They solve a problem well enough that Ingo had in effect
> > > reinvented them on Friday.
> > 
> > Because after a printk() debug spree, I don't commit them, I toss them
> > out and keep the fix.
> 
> Markers solve a problem closer to tracepoints than to debugging
> printk's.

Not so. In both cases the regular stuff (NMI trace, OOPS,
function/graph/sched trace, etc) is not enough and you wish to augment
its output.

> In this context, the main difference between tracepoints is that
> markers need almost no hand-written glue code of the sort that make up
> ftrace engines that just trace simple values.  Simpler & smaller code
> for the same output seems like a win.

Right, for dumb tracers that's true I suppose, however any
high-bandwidth tracer will try to avoid putting silly ASCII strings in
and will therefore need to write more glue code.

Which reduces these default thingies to printk() level debugging.


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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-23 11:11             ` Peter Zijlstra
@ 2009-02-23 15:44               ` Frank Ch. Eigler
  2009-02-23 16:22                 ` Peter Zijlstra
  0 siblings, 1 reply; 45+ messages in thread
From: Frank Ch. Eigler @ 2009-02-23 15:44 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Randy Dunlap, Frederic Weisbecker, Steven Rostedt,
	linux-kernel, zippel, linux-kbuild

Hi -

On Mon, Feb 23, 2009 at 12:11:27PM +0100, Peter Zijlstra wrote:
> [...]
> > > Because after a printk() debug spree, I don't commit them, I toss them
> > > out and keep the fix.
> > 
> > Markers solve a problem closer to tracepoints than to debugging
> > printk's.

> Not so. In both cases the regular stuff (NMI trace, OOPS,
> function/graph/sched trace, etc) is not enough and you wish to
> augment its output.

Sorry, I don't see how that relates.  If the general function tracing
widgetry is insufficient for some subsystem/purpose, some sort of
static instrumentation is needed.  Whether that instrumentation is
done by markers (with a thin glue to ftrace) or by tracepoints (with a
thick glue to ftrace) doesn't change the need for "augmentation".


> > In this context, the main difference between tracepoints is that
> > markers need almost no hand-written glue code of the sort that make up
> > ftrace engines that just trace simple values.  Simpler & smaller code
> > for the same output seems like a win.
> 
> Right, for dumb tracers that's true I suppose, however any
> high-bandwidth tracer will try to avoid putting silly ASCII strings in
> and will therefore need to write more glue code.

So let's leave it up to the wisdom of each subsystem maintainer to
decide whether any particular trace event is high enough throughput
that direct ASCII rendering is not favourable.  (Considering the
finite size of tracing buffers, high-throughput trace events would
need to be continually drained with ASCII conversion anyway, so the
overall benefit of using packed binary as an intermediate copy may not
be large after all.)

I see all this as an argument to keep the subsystem's options open.
Sometimes the extra complexity of tracepoints is worth it, sometimes
it isn't.

- FChE

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-23 15:44               ` Frank Ch. Eigler
@ 2009-02-23 16:22                 ` Peter Zijlstra
  2009-02-23 17:10                   ` Frank Ch. Eigler
  0 siblings, 1 reply; 45+ messages in thread
From: Peter Zijlstra @ 2009-02-23 16:22 UTC (permalink / raw)
  To: Frank Ch. Eigler
  Cc: Ingo Molnar, Randy Dunlap, Frederic Weisbecker, Steven Rostedt,
	linux-kernel, zippel, linux-kbuild

On Mon, 2009-02-23 at 10:44 -0500, Frank Ch. Eigler wrote:
> Hi -
> 
> On Mon, Feb 23, 2009 at 12:11:27PM +0100, Peter Zijlstra wrote:
> > [...]
> > > > Because after a printk() debug spree, I don't commit them, I toss them
> > > > out and keep the fix.
> > > 
> > > Markers solve a problem closer to tracepoints than to debugging
> > > printk's.
> 
> > Not so. In both cases the regular stuff (NMI trace, OOPS,
> > function/graph/sched trace, etc) is not enough and you wish to
> > augment its output.
> 
> Sorry, I don't see how that relates.  If the general function tracing
> widgetry is insufficient for some subsystem/purpose, some sort of
> static instrumentation is needed.  Whether that instrumentation is
> done by markers (with a thin glue to ftrace) or by tracepoints (with a
> thick glue to ftrace) doesn't change the need for "augmentation".

I'm not arguing against static instrumentation per-se (although
expanding the coverage of dynamic/automatic instrumentation is much more
profitable IMHO).

What I'm arguing is that trace_mark()s one distinguishing feature over
tracepoints is only suited for quick debug like work.

Furthermore, trace_mark() exposes that crap like an ABI, now suppose
some distro goes and declares that stable for some daft reason, imagine
the poor sod having to fix something littered with trace_mark().

Look at fs/ext4/ for a particularly horrid example.

[ quite apart from why I hate trace_mark() most -- which is that it
makes the code look like someone committed their tree after a debugging
session ]

> > > In this context, the main difference between tracepoints is that
> > > markers need almost no hand-written glue code of the sort that make up
> > > ftrace engines that just trace simple values.  Simpler & smaller code
> > > for the same output seems like a win.
> > 
> > Right, for dumb tracers that's true I suppose, however any
> > high-bandwidth tracer will try to avoid putting silly ASCII strings in
> > and will therefore need to write more glue code.
> 
> So let's leave it up to the wisdom of each subsystem maintainer to
> decide whether any particular trace event is high enough throughput
> that direct ASCII rendering is not favourable.  (Considering the
> finite size of tracing buffers, high-throughput trace events would
> need to be continually drained with ASCII conversion anyway, so the
> overall benefit of using packed binary as an intermediate copy may not
> be large after all.)
> 
> I see all this as an argument to keep the subsystem's options open.
> Sometimes the extra complexity of tracepoints is worth it, sometimes
> it isn't.

It always is, either the information is useful, or it isn't. If it isn't
we shouldn't have it in tree. If it is, you never know how people will
want to use it.

Big but low-rate events will take space that could have been properly
used to capture longer - giving a better view of subsystem interaction.

Tracing transcends sub-systems in that sense, its not about
per-subsystem tracers, its about full overview, and whilst subsystem
maintainers can help in determining what information is useful,
presenting that information in big bloated blobs is beyond that scope.




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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-23 16:22                 ` Peter Zijlstra
@ 2009-02-23 17:10                   ` Frank Ch. Eigler
  2009-02-23 17:23                     ` Ingo Molnar
  2009-02-23 17:31                     ` Steven Rostedt
  0 siblings, 2 replies; 45+ messages in thread
From: Frank Ch. Eigler @ 2009-02-23 17:10 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Randy Dunlap, Frederic Weisbecker, Steven Rostedt,
	linux-kernel, zippel, linux-kbuild

On Mon, Feb 23, 2009 at 05:22:39PM +0100, Peter Zijlstra wrote:
> [...]
> > > Not so. In both cases the regular stuff (NMI trace, OOPS,
> > > function/graph/sched trace, etc) is not enough and you wish to
> > > augment its output.
> > 
> > Sorry, I don't see how that relates.  If the general function tracing
> > widgetry is insufficient for some subsystem/purpose, some sort of
> > static instrumentation is needed.  Whether that instrumentation is
> > done by markers (with a thin glue to ftrace) or by tracepoints (with a
> > thick glue to ftrace) doesn't change the need for "augmentation".
> 
> I'm not arguing against static instrumentation per-se (although
> expanding the coverage of dynamic/automatic instrumentation is much more
> profitable IMHO).

Much prior discussion (incl. at the kernel summit) indicates that we
need both.

> What I'm arguing is that trace_mark()s one distinguishing feature over
> tracepoints is only suited for quick debug like work.

I see where you're coming from, but one may also caricaturize the
other alternative as requiring make-work glue code to pack & unpack
all the same inforation.


> Furthermore, trace_mark() exposes that crap like an ABI, now suppose
> some distro goes and declares that stable for some daft reason,
> imagine the poor sod having to fix something littered with
> trace_mark().

The impression that this is somehow different with tracepoints is
mistaken.  Tracepoints are *exactly* as "ABI-like" as markers.


> [...]  presenting that information in big bloated blobs is beyond
> that scope.

Do you have some specific bloated blobs in mind?  It's not as if the
rendered text is necessarily much bigger than a struct containing all
the same parameters.  Consider all the fields rounded up to 4 or 8
bytes each.


- FChE

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-23 17:10                   ` Frank Ch. Eigler
@ 2009-02-23 17:23                     ` Ingo Molnar
  2009-02-24 13:01                       ` Frank Ch. Eigler
  2009-02-23 17:31                     ` Steven Rostedt
  1 sibling, 1 reply; 45+ messages in thread
From: Ingo Molnar @ 2009-02-23 17:23 UTC (permalink / raw)
  To: Frank Ch. Eigler
  Cc: Peter Zijlstra, Randy Dunlap, Frederic Weisbecker,
	Steven Rostedt, linux-kernel, zippel, linux-kbuild


* Frank Ch. Eigler <fche@redhat.com> wrote:

> > Furthermore, trace_mark() exposes that crap like an ABI, now 
> > suppose some distro goes and declares that stable for some 
> > daft reason, imagine the poor sod having to fix something 
> > littered with trace_mark().
> 
> The impression that this is somehow different with tracepoints 
> is mistaken.  Tracepoints are *exactly* as "ABI-like" as 
> markers.

they arent. To the kernel they look like function calls, with no 
ABI properties at all. They can and will change without notice.

	Ingo

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-23 17:10                   ` Frank Ch. Eigler
  2009-02-23 17:23                     ` Ingo Molnar
@ 2009-02-23 17:31                     ` Steven Rostedt
  2009-02-23 18:32                       ` Theodore Tso
  1 sibling, 1 reply; 45+ messages in thread
From: Steven Rostedt @ 2009-02-23 17:31 UTC (permalink / raw)
  To: Frank Ch. Eigler
  Cc: Peter Zijlstra, Ingo Molnar, Randy Dunlap, Frederic Weisbecker,
	linux-kernel, zippel, linux-kbuild


On Mon, 23 Feb 2009, Frank Ch. Eigler wrote:
> 
> > Furthermore, trace_mark() exposes that crap like an ABI, now suppose
> > some distro goes and declares that stable for some daft reason,
> > imagine the poor sod having to fix something littered with
> > trace_mark().
> 
> The impression that this is somehow different with tracepoints is
> mistaken.  Tracepoints are *exactly* as "ABI-like" as markers.
> 

I disagree with this point. markers are text strings that will eventually 
appear to userspace. trace points need translation. A trace point can be 
modified at any time and should never mess up user apps.

You may have a hook to a trace point that provides user apps a text based 
output. If the trace point changes, this hook may break. But the tracer 
maintainer of that hook will be responsible for that change, not the 
maintainer of the code the tracepoint existed in.

-- Steve


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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-23 17:31                     ` Steven Rostedt
@ 2009-02-23 18:32                       ` Theodore Tso
  2009-02-23 22:16                         ` Peter Zijlstra
  0 siblings, 1 reply; 45+ messages in thread
From: Theodore Tso @ 2009-02-23 18:32 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Frank Ch. Eigler, Peter Zijlstra, Ingo Molnar, Randy Dunlap,
	Frederic Weisbecker, linux-kernel, zippel, linux-kbuild

On Mon, Feb 23, 2009 at 12:31:31PM -0500, Steven Rostedt wrote:
> > The impression that this is somehow different with tracepoints is
> > mistaken.  Tracepoints are *exactly* as "ABI-like" as markers.
> 
> I disagree with this point. markers are text strings that will eventually 
> appear to userspace. trace points need translation. A trace point can be 
> modified at any time and should never mess up user apps.
> 
> You may have a hook to a trace point that provides user apps a text based 
> output. If the trace point changes, this hook may break. But the tracer 
> maintainer of that hook will be responsible for that change, not the 
> maintainer of the code the tracepoint existed in.

So stupid question time --- exactly who is supposed to write and
maintain trnaslation code; the "hook"?  What trace points have done is
added an extra layer of indirection, but in order for someone to
actually make *use* of the have the trace point, someone has to
maintain the "hook".

I'm sorry I've offended Peter with the ext4 trace_mark() hooks, but
it's what I could forsee needing if someone wants reports a wierd sh*t
bug in ext4 and I wanted to be able to be able to extract debugging
information without forcing them to patch and recompile the kernel,
and in the ideal world, without even needing to reboot the kernel.
(If we had usable and reliable debuginfo information, in most cases
I'd be able simply use access to function parameters as replacements
for trace_mark().)

I've had to debug problems in the field on customer machines where
installing a new kernel was a big deal (as in, you get a window to
reboot the machine every 24 hours, and the problem is so complex you
can't replicate it anywhere *but* the production environment).  It's
also been the case that more than once I've seen wierd behaviour on my
laptop, and being able to peer inside it to see what is going on
easily and conveniently is a major win.

My big complaint with tracepoints is specifically *that* I need to
write a lot of hook code each time I want to investigate something.
So to say it's more maintabile because it doesn't present an ABI is a
bit of sophistry, I think.  Yes, there's no ABI because each time you
want to do something different, you have to roll your own kernel
module code to write the hook from scratch --- taking something that
was a "gee, I wonder...." 30 second experiment to something which
takes 5-10 times longer, at minimum.


Finally, whether or not the text string is an ABI really depends on
the tools.  Given that the string is self describing, it's only an ABI
if the tools are stupid.  It doesn't take that much extra parsing
smarts to be able to under stand a format string of:

	dev %s dir %lu mode %d

and DTRT if the kernel instead hands back something which was
constructed with the format string:

	dev %s dir %lu mode %d grp %u

or even:

	dev %s dir %lu

if the mode parameter is unavailable for whatever reason in future
kernel versions.  This really isn't rocket science....

					- Ted

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-23 18:32                       ` Theodore Tso
@ 2009-02-23 22:16                         ` Peter Zijlstra
  2009-02-23 22:41                           ` Theodore Tso
  0 siblings, 1 reply; 45+ messages in thread
From: Peter Zijlstra @ 2009-02-23 22:16 UTC (permalink / raw)
  To: Theodore Tso
  Cc: Steven Rostedt, Frank Ch. Eigler, Ingo Molnar, Randy Dunlap,
	Frederic Weisbecker, linux-kernel, zippel, linux-kbuild

On Mon, 2009-02-23 at 13:32 -0500, Theodore Tso wrote:
> On Mon, Feb 23, 2009 at 12:31:31PM -0500, Steven Rostedt wrote:
> > > The impression that this is somehow different with tracepoints is
> > > mistaken.  Tracepoints are *exactly* as "ABI-like" as markers.
> > 
> > I disagree with this point. markers are text strings that will eventually 
> > appear to userspace. trace points need translation. A trace point can be 
> > modified at any time and should never mess up user apps.
> > 
> > You may have a hook to a trace point that provides user apps a text based 
> > output. If the trace point changes, this hook may break. But the tracer 
> > maintainer of that hook will be responsible for that change, not the 
> > maintainer of the code the tracepoint existed in.
> 
> So stupid question time --- exactly who is supposed to write and
> maintain trnaslation code; the "hook"?  What trace points have done is
> added an extra layer of indirection, but in order for someone to
> actually make *use* of the have the trace point, someone has to
> maintain the "hook".

That just means we have to make it easier to write/generate this glue,
no? If we had function argument debug data (see below) we could generate
a generic tracepoint hook.

> I'm sorry I've offended Peter with the ext4 trace_mark() hooks, but
> it's what I could forsee needing if someone wants reports a wierd sh*t
> bug in ext4 and I wanted to be able to be able to extract debugging
> information without forcing them to patch and recompile the kernel,
> and in the ideal world, without even needing to reboot the kernel.
> (If we had usable and reliable debuginfo information, in most cases
> I'd be able simply use access to function parameters as replacements
> for trace_mark().)

We're working on adding arguments to the function/graph tracer, it would
fit all your above requirements and doesn't need any source modification
to boot.

Furthermore, most of it is upstream.

> I've had to debug problems in the field on customer machines where
> installing a new kernel was a big deal (as in, you get a window to
> reboot the machine every 24 hours, and the problem is so complex you
> can't replicate it anywhere *but* the production environment).  It's
> also been the case that more than once I've seen wierd behaviour on my
> laptop, and being able to peer inside it to see what is going on
> easily and conveniently is a major win.

Yeah, I know, the function graph tracer is brilliant that way. It even
provides information on the rest of the system and requires no
additional patches or big lumps of userspace.

> Finally, whether or not the text string is an ABI really depends on
> the tools.  Given that the string is self describing, it's only an ABI
> if the tools are stupid.  

>  This really isn't rocket science....

It isn't, yet how many scripts/programs have you seen that failed at the
above?



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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-23 22:16                         ` Peter Zijlstra
@ 2009-02-23 22:41                           ` Theodore Tso
  2009-02-24  8:55                             ` Peter Zijlstra
  0 siblings, 1 reply; 45+ messages in thread
From: Theodore Tso @ 2009-02-23 22:41 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Steven Rostedt, Frank Ch. Eigler, Ingo Molnar, Randy Dunlap,
	Frederic Weisbecker, linux-kernel, zippel, linux-kbuild

On Mon, Feb 23, 2009 at 11:16:59PM +0100, Peter Zijlstra wrote:
> 
> We're working on adding arguments to the function/graph tracer, it would
> fit all your above requirements and doesn't need any source modification
> to boot.

*Excellent*.  I would love to have that funtionality.  How do you plan
to make available complex data structures (i.e., suppose I want
inode->i_ino printed out)?  I assume this will require writing some
"easy to generate" glue code that would presumably be some kind of
kernel module?  That doesn't bother me (after all that's what
SystemTap does), as long as generation of the glue code can be largely
automated ---- so that you can take something approximately like a
DTrace or SystemTap script, and with some perl or python helper,
translate it into glue code that gets compiled into a kernel module.
Is something like that what you have in mind?

   	        	     	       	    	     	- Ted

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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-23 22:41                           ` Theodore Tso
@ 2009-02-24  8:55                             ` Peter Zijlstra
  0 siblings, 0 replies; 45+ messages in thread
From: Peter Zijlstra @ 2009-02-24  8:55 UTC (permalink / raw)
  To: Theodore Tso
  Cc: Steven Rostedt, Frank Ch. Eigler, Ingo Molnar, Randy Dunlap,
	Frederic Weisbecker, linux-kernel, zippel, linux-kbuild

On Mon, 2009-02-23 at 17:41 -0500, Theodore Tso wrote:
> On Mon, Feb 23, 2009 at 11:16:59PM +0100, Peter Zijlstra wrote:
> > 
> > We're working on adding arguments to the function/graph tracer, it would
> > fit all your above requirements and doesn't need any source modification
> > to boot.
> 
> *Excellent*.  I would love to have that funtionality.  How do you plan
> to make available complex data structures (i.e., suppose I want
> inode->i_ino printed out)?  I assume this will require writing some
> "easy to generate" glue code that would presumably be some kind of
> kernel module?  That doesn't bother me (after all that's what
> SystemTap does), as long as generation of the glue code can be largely
> automated ---- so that you can take something approximately like a
> DTrace or SystemTap script, and with some perl or python helper,
> translate it into glue code that gets compiled into a kernel module.
> Is something like that what you have in mind?

Yeah, we were also looking at using sparse and term rewrite systems on
top of the regular C parse tree to generate stuff.


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

* Re: [PATCH] tracing/markers: make markers select tracepoints
  2009-02-23 17:23                     ` Ingo Molnar
@ 2009-02-24 13:01                       ` Frank Ch. Eigler
  0 siblings, 0 replies; 45+ messages in thread
From: Frank Ch. Eigler @ 2009-02-24 13:01 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Peter Zijlstra, Randy Dunlap, Frederic Weisbecker,
	Steven Rostedt, linux-kernel, zippel, linux-kbuild

Hi -

> > The impression that this is somehow different with tracepoints 
> > is mistaken.  Tracepoints are *exactly* as "ABI-like" as 
> > markers.
> 
> they arent. To the kernel they look like function calls, with no 
> ABI properties at all. They can and will change without notice.

Markers also "look like" function calls because they are - the
callbacks just happen to take a format string and varargs.  What did
you think they were?


srostedt argues that separating the tracepoint from its rendering is
necessary to free the instrumentation site from backward-compatibility
stagnation.  

But consider - it has been manifold stated that tracepoints are not
welcome in the tree without a "tracer" (hand-written glue), so the
same person ends up writing both.  Since they are tightly coupled.  a
change on one will affect the other.  A moved tracepoint will produce
events at different times; a lost tracepoint parameter will lose data
at trace rendering time.  The tracing engine can only pretend to
produce the same data by guessing.

Similarly, if a marker site were to change, and if someone deemed the
old trace data important to preserve, a hand-written marker callback
function could replace a generic one, The new one could make the same
heuristic adaptation.

Try working out some examples.  You'll probably see how similar they
really turn out, with respect to the hypothetical "preserve ABI" idea.

- FChE

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

end of thread, other threads:[~2009-02-24 13:02 UTC | newest]

Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-20 16:34 [PATCH] tracing/markers: make markers select tracepoints Frederic Weisbecker
2009-02-20 16:59 ` Randy Dunlap
2009-02-20 17:20   ` Frederic Weisbecker
2009-02-20 17:22   ` Ingo Molnar
2009-02-20 17:29     ` Randy Dunlap
2009-02-20 17:31     ` Frederic Weisbecker
2009-02-20 17:48       ` Ingo Molnar
2009-02-20 18:56         ` Jason Baron
2009-02-21  3:15         ` Frederic Weisbecker
2009-02-21 22:04         ` Frank Ch. Eigler
2009-02-22 17:13           ` Ingo Molnar
2009-02-22 17:38             ` Frank Ch. Eigler
2009-02-23 10:13         ` Avi Kivity
2009-02-22  3:23     ` KOSAKI Motohiro
2009-02-22 11:37       ` Peter Zijlstra
2009-02-22 16:04         ` Mathieu Desnoyers
2009-02-22 19:17           ` Ingo Molnar
2009-02-23  2:47             ` Mathieu Desnoyers
2009-02-23  8:52               ` Ingo Molnar
2009-02-22 11:43     ` Peter Zijlstra
2009-02-22 12:08       ` Frank Ch. Eigler
2009-02-22 12:14         ` Peter Zijlstra
2009-02-22 12:24           ` Frank Ch. Eigler
2009-02-23 11:11             ` Peter Zijlstra
2009-02-23 15:44               ` Frank Ch. Eigler
2009-02-23 16:22                 ` Peter Zijlstra
2009-02-23 17:10                   ` Frank Ch. Eigler
2009-02-23 17:23                     ` Ingo Molnar
2009-02-24 13:01                       ` Frank Ch. Eigler
2009-02-23 17:31                     ` Steven Rostedt
2009-02-23 18:32                       ` Theodore Tso
2009-02-23 22:16                         ` Peter Zijlstra
2009-02-23 22:41                           ` Theodore Tso
2009-02-24  8:55                             ` Peter Zijlstra
2009-02-23  0:23       ` Steven Rostedt
2009-02-21  5:24   ` [PATCH][RFC] check for select dependency errors on config load Steven Rostedt
2009-02-21  5:58     ` Andrew Morton
2009-02-21  6:08     ` Andrew Morton
2009-02-21  6:20       ` Randy Dunlap
2009-02-21 20:07         ` Steven Rostedt
2009-02-21 20:46           ` [PATCH v2] kconfig: " Steven Rostedt
2009-02-21 20:48             ` Steven Rostedt
2009-02-21 21:51             ` Sam Ravnborg
2009-02-21 21:53               ` Steven Rostedt
2009-02-22 16:23     ` [PATCH][RFC] " Ingo Molnar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).