From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH 2/2] kvm: use cpumask_var_t for cpus_hardware_enabled
Date: Sun, 07 Dec 2008 17:55:50 +0200
Message-ID: <493BF206.4070007@redhat.com>
References: <200812072125.45757.rusty@rustcorp.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kvm-devel <kvm@vger.kernel.org>, linux-kernel@vger.kernel.org,
	Mike Travis <travis@sgi.com>, Avi Kivity <avi@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Return-path: <kvm-owner@vger.kernel.org>
In-Reply-To: <200812072125.45757.rusty@rustcorp.com.au>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

Rusty Russell wrote:
> This changes cpus_hardware_enabled from a cpumask_t to a cpumask_var_t:
> equivalent for CONFIG_CPUMASKS_OFFSTACK=n, otherwise dynamically allocated.
>
>  
> -static cpumask_t cpus_hardware_enabled;
> +static cpumask_var_t cpus_hardware_enabled

This isn't on stack, so it isn't buying us anything.

Is the plan to drop cpumask_t?  If so, we're penalizing non-stack users 
by forcing them to go through another pointer (and cacheline).



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