* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Thu, 15 Nov 2007 21:23:19 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]>
> wrote:
>
> > * Andrew Morton ([EMAIL PROTECTED]) wrote:
> > > On Thu, 15 Nov 2007 20:59:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > arch/x86/Kco
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like kernel/Kconfig.instrumen
On Thu, 15 Nov 2007 21:23:19 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> * Andrew Morton ([EMAIL PROTECTED]) wrote:
> > On Thu, 15 Nov 2007 20:59:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]>
> > wrote:
> >
> > > arch/x86/Kconfig.i386 |1 +
> > > arch/x86/Kconfig.x86_64
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Thu, 15 Nov 2007 20:59:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]>
> wrote:
>
> > arch/x86/Kconfig.i386 |1 +
> > arch/x86/Kconfig.x86_64|1 +
>
> these no longer exist.
Ok, should I prepare a fix or is it duplicated wo
On Thu, 15 Nov 2007 20:59:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> arch/x86/Kconfig.i386 |1 +
> arch/x86/Kconfig.x86_64|1 +
these no longer exist.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like kernel/Kconfig.instrumen
> >
> >
> > In the arch specific Kconfig file in a suitable place do:
> >
> > config SUITABLE_OPTION
>
> Since config KPROBES will already be used in the architecture
> independent Kconfig, I should find a different name for "config
> SUITABLE_OPTION". Would
>
> config KPROBES_SUPPORT
> sele
* Sam Ravnborg ([EMAIL PROTECTED]) wrote:
> Hi Mathieu.
>
> >
> > It would be much better to do
> >
> > depends on ARCH_SUPPORTS_KPROBES
> >
> > in that generic file, and then architectures that do support it would just
> > have a
> >
> > bool ARCH_SUPPORTS_KPROBES
> >
Hi Mathieu.
>
> It would be much better to do
>
> depends on ARCH_SUPPORTS_KPROBES
>
> in that generic file, and then architectures that do support it would just
> have a
>
> bool ARCH_SUPPORTS_KPROBES
> default y
The above suggestion is actually not exactly th
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like kernel/Kconfig.instrumen
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like kernel/Kconfig.instrumen
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like kernel/Kconfig.instrumen
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like kernel/Kconfig.instrumen
13 matches
Mail list logo
