From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: Re: Xen/ia64 presentation Date: Wed, 27 Apr 2005 14:31:16 -0500 Message-ID: <426FE884.2010904@us.ibm.com> References: <516F50407E01324991DD6D07B0531AD535AFC4@cacexc12.americas.cpqcorp.net> <426FE40C.60102@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "Magenheimer, Dan (HP Labs Fort Collins)" , Xen-devel List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > > I think I agree that 'struct vcpu' is nicer than 'struct exec_domain'. > exec_domain appears hardly at all at the hypervisor interface, and > having two different terms used interchangeably within Xen itself is weird. > > Another I can think of is cpuset vs. cpumask: I went with the former but > I like the latter equally well and there is no good reason not to go > with the Linux convention on this one. > > Perhaps we should have a flag day to move to agreed consistent naming on > some of these? The changes are trivially scriptable for the most part, > but annoying for those with pending patches. Sounds good to me. On this subject, I'd also like to ask about full_execution_context_t. execution_context_t is used in a fair number of places in the Xen core; however full_execution_context_t seems to only be used in the dom0 interface. The in-Xen analog to full_execution_context_t is arch_exec_domain, with many fields duplicated between the two. Could we consolidate these, or at least give full_execution_context_t a name that better describes its purpose? -- Hollis Blanchard IBM Linux Technology Center