[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070907124648.GC9735@Krystal>
Date: Fri, 7 Sep 2007 08:46:48 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To: Andi Kleen <andi@...stfloor.org>
Cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
Adrian Bunk <bunk@...sta.de>,
Alexey Dobriyan <adobriyan@...il.com>,
Christoph Hellwig <hch@...radead.org>
Subject: Re: [patch 3/8] Immediate Values - Kconfig menu in EMBEDDED
* Andi Kleen (andi@...stfloor.org) wrote:
> > +config IMMEDIATE
> > + default y if !DISABLE_IMMEDIATE
>
> It's still unclear to me why DISABLE_IMMEDIATE is needed. It would
> be better to make it just the default.
>
It is actually the default on any non embedded configuration. Do you
think we should make it default to on on embedded configs too ?
> > +config DISABLE_IMMEDIATE
> > + default y if EMBEDDED
> > + bool "Disable immediate values" if EMBEDDED
> > + depends on X86_32 || PPC || PPC64
> > + help
> > + Disable code patching based immediate values for embedded systems. It
> > + consumes slightly more memory and requires to modify the instruction
> > + stream each time a variable is updated.
>
> > Should really be disabled for
> > + embedded systems with read-only text.
>
> There are no such on x86 at least And for other architectures like
> PPC it would be better to have a high level CONFIG_READ_ONLY_TEXT
> then that does the necessary changes internally. But I'm not sure it's even
> supporting r/o text.
>
The idea here is to give embedded system developers incentives to
create an optimized immediate value header for their architecture. I
fear that if it is not trivial to disable when they need to use ROM to
put the kernel code (as kprobes is, meaning, with a single config
option), they will refuse to event think about including an optimized
immediate value header for their architecture.
And yes, having a CONFIG_READ_ONLY_TEXT makes sense, but it implies
menu dependencies with not only immediate values but also kprobes,
paravirt, alternatives, (am I missing others ?)
As long as we find a way for people to disable _all_ code patching in
their kernel, I'm happy with that. But since every existing code
patching mechanism can currently be disabled one by one, it makes sense
to do the same for the immediate values. Having a global
CONFIG_READ_ONLY_TEXT should IMHO come in a separate effort.
Mathieu
> -Andi
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists