WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 3/6] eliminate cpu_set()

To: "Keir Fraser" <keir@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH 3/6] eliminate cpu_set()
From: "Jan Beulich" <JBeulich@xxxxxxxx>
Date: Mon, 07 Nov 2011 07:52:30 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 07 Nov 2011 06:53:14 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CADDA02F.33AD3%keir@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4EB7FBB7020000780005F5E9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CADDA02F.33AD3%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 07.11.11 at 15:48, Keir Fraser <keir@xxxxxxx> wrote:
> On 07/11/2011 14:39, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>>> I don't like set_cpu_{present,online} taking a boolean clear/set flag. There
>>> is no caller that can both set and clear a flag, so it is always hardcoded
>>> as 0 or 1. And then the reader has to make a (probably not hard) guess what
>>> that means.
>>> 
>>> If you must add an abstraction interface here, better to define four of
>>> them: {set,clear}_cpu_{present,online}.
>> 
>> Hmm, I don't like this interface design too much either, but again wanted
>> to follow Linux rather than cooking our own. Do you really want us to
>> diverge in this respect?
> 
> Yes. Apart from maybe the code that tickles the remote APIC, our smpboot
> code is already well diverged from Linux.

In that case I'd prefer not having a separate abstraction here at all - is
that fine by you?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel