>>> On 01.09.15 at 19:55, wrote:
> "Jan Beulich" writes:
>
> On 01.09.15 at 16:29, wrote:
>>
>> Which is both appreciated and understandable. I suppose you
>> agree though that if you were to follow the model
On 02/09/15 07:53, Jan Beulich wrote:
On 01.09.15 at 19:55, wrote:
>> "Jan Beulich" writes:
>>
>> On 01.09.15 at 16:29, wrote:
>>> Which is both appreciated and understandable. I suppose you
>>> agree
"Jan Beulich" writes:
On 01.09.15 at 16:29, wrote:
Which is both appreciated and understandable. I suppose you
agree though that if you were to follow the model used for the
kexec part, things would quickly become unwieldy. Hence I would
>>> On 01.09.15 at 12:44, wrote:
> On 01/09/15 11:36, Ian Campbell wrote:
>> In general (i.e. not 100% consistently, I think) we have tended to avoid
>> making things user-facing compile time options. Many of the existing
>> CONFIG_* and HAVE_* are really about things
On 01/09/15 11:36, Ian Campbell wrote:
> On Thu, 2015-08-27 at 10:44 -0500, Jonathan Creekmore wrote:
>>> On Aug 27, 2015, at 10:27 AM, David Vrabel
>>> wrote:
>>>
>>> On 27/08/15 15:47, Jonathan Creekmore wrote:
Add the appropriate #if checks around the kexec code
On Thu, 2015-08-27 at 10:44 -0500, Jonathan Creekmore wrote:
> >
> > On Aug 27, 2015, at 10:27 AM, David Vrabel
> > wrote:
> >
> > On 27/08/15 15:47, Jonathan Creekmore wrote:
> > > Add the appropriate #if checks around the kexec code in the x86
> > > codebase
> > >
On 01/09/15 11:54, Jan Beulich wrote:
On 01.09.15 at 12:44, wrote:
>> On 01/09/15 11:36, Ian Campbell wrote:
>>> In general (i.e. not 100% consistently, I think) we have tended to avoid
>>> making things user-facing compile time options. Many of the existing
>>>
>>> On 01.09.15 at 16:29, wrote:
> I am not interested in unnecessarily stripping out more and more
> code. However, I do want to reduce the number of features and
> backwards-compatibility code-paths that are compiled into my
> build. Areas like the 32-bit ABI on
Andrew Cooper writes:
On 01/09/15 11:54, Jan Beulich wrote:
On 01.09.15 at 12:44, wrote:
On 01/09/15 11:36, Ian Campbell wrote:
In general (i.e. not 100% consistently, I think) we have
tended to avoid making things user-facing compile
On 27.08.15 at 17:22, andrew.coop...@citrix.com wrote:
On 27/08/15 15:47, Jonathan Creekmore wrote:
@@ -812,7 +816,11 @@ ENTRY(hypercall_args_table)
.byte 2 /* do_hvm_op*/
.byte 1 /* do_sysctl*/ /* 35 */
.byte 1 /* do_domctl*/
On 27/08/15 16:34, Jan Beulich wrote:
On 27.08.15 at 17:22, andrew.coop...@citrix.com wrote:
On 27/08/15 15:47, Jonathan Creekmore wrote:
@@ -812,7 +816,11 @@ ENTRY(hypercall_args_table)
.byte 2 /* do_hvm_op*/
.byte 1 /* do_sysctl*/ /* 35 */
On 27/08/15 15:47, Jonathan Creekmore wrote:
Add the appropriate #if checks around the kexec code in the x86 codebase
so that the feature can actually be turned off by the flag instead of
always required to be enabled on x86.
What's your use case for this?
I think you should consider
On Aug 27, 2015, at 10:27 AM, David Vrabel david.vra...@citrix.com wrote:
On 27/08/15 15:47, Jonathan Creekmore wrote:
Add the appropriate #if checks around the kexec code in the x86 codebase
so that the feature can actually be turned off by the flag instead of
always required to be
On 27.08.15 at 16:47, jonathan.creekm...@gmail.com wrote:
Add the appropriate #if checks around the kexec code in the x86 codebase
so that the feature can actually be turned off by the flag instead of
always required to be enabled on x86.
But you realize that these HAVE_* variables aren't
On 27/08/15 15:47, Jonathan Creekmore wrote:
Add the appropriate #if checks around the kexec code in the x86 codebase
so that the feature can actually be turned off by the flag instead of
always required to be enabled on x86.
Signed-off-by: Jonathan Creekmore jonathan.creekm...@gmail.com
In
On 27.08.15 at 17:27, david.vra...@citrix.com wrote:
On 27/08/15 15:47, Jonathan Creekmore wrote:
@@ -125,6 +126,22 @@ do {\
cpu_relax();\
}
16 matches
Mail list logo