From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LrYip-0001WR-Sm
	for qemu-devel@nongnu.org; Wed, 08 Apr 2009 10:25:47 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LrYil-0001Uj-7j
	for qemu-devel@nongnu.org; Wed, 08 Apr 2009 10:25:47 -0400
Received: from [199.232.76.173] (port=57861 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LrYil-0001UZ-1J
	for qemu-devel@nongnu.org; Wed, 08 Apr 2009 10:25:43 -0400
Received: from mx2.redhat.com ([66.187.237.31]:47509)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1LrYik-0005ri-JI
	for qemu-devel@nongnu.org; Wed, 08 Apr 2009 10:25:42 -0400
Message-ID: <49DCB3E1.4030108@redhat.com>
Date: Wed, 08 Apr 2009 16:25:37 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 02/10] xen: backend driver core
References: <1239115497-1884-1-git-send-email-kraxel@redhat.com>
	<1239115497-1884-3-git-send-email-kraxel@redhat.com>
	<49DBAC54.7010500@us.ibm.com> <49DC6CB7.8000602@redhat.com>
	<49DCA3CF.1080905@us.ibm.com>
In-Reply-To: <49DCA3CF.1080905@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org

On 04/08/09 15:17, Anthony Liguori wrote:
> I meant the public stuff too. I don't like having extern variables all
> over the place.
>
> It would be better to have this in a structure that was passed to all of
> the backend drivers that they then passed as a context. This will become
> more useful down the road too when we start introducing a common device
> model and finer grain locking.

The variables are more global xen state, not device / xenbus state. The 
usage is not limited to the backend drivers, the domain builder code 
will use them as well.  There will never ever be more than one instance 
of these.  I don't see the point of placing them into a struct and 
passing around a pointer.

cheers,
   Gerd