In-Reply-To: <20060513052750.41cfcb9d.akpm@osdl.org>
References: <20060509084945.373541000@sous-sol.org> <20060509085157.491027000@sous-sol.org> <20060513052750.41cfcb9d.akpm@osdl.org>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <6c98457a59001e5e833121fb65075d00@cl.cam.ac.uk>
Content-Transfer-Encoding: 7bit
Cc: virtualization@lists.osdl.org, linux-kernel@vger.kernel.org,
       xen-devel@lists.xensource.com, ian.pratt@xensource.com,
       Chris Wright <chrisw@sous-sol.org>
From: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Subject: Re: [RFC PATCH 24/35] Add support for Xen event channels.
Date: Sat, 13 May 2006 14:02:58 +0100
To: Andrew Morton <akpm@osdl.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1046
Lines: 32


On 13 May 2006, at 13:27, Andrew Morton wrote:

>
>> +	init_evtchn_cpu_bindings();
>> +
>> +	/* No VIRQ or IPI bindings. */
>> +	for (cpu = 0; cpu < NR_CPUS; cpu++) {
>
> Using NR_CPUS is a little...  old-fashioned.  I'd suggest a sweep 
> through
> all the Xen code, look for places where it should be using
> for_each_foo_cpu().

Actually that's a particularly good catch in this case, since we use 
per_cpu() inside the loop and that's only well defined for 
cpu_possible_map. Oops.

The elusive users of ring.h are our split device drivers. It hides a 
bunch of details about muxing requests and responses on the same ring, 
and notification thresholds. There are a few other places we have ring 
buffers but they are sufficiently simple that implementing in place is 
clearer.

  Thanks,
  Keir

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/