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

[XenPPC] Re: [Xen-devel] [PATCH] don't use mlock() with Solaris tools

To: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>
Subject: [XenPPC] Re: [Xen-devel] [PATCH] don't use mlock() with Solaris tools
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 23 Oct 2006 09:46:11 +0100
Cc: XenPPC-devel <xen-ppc-devel@xxxxxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Hollis R. Blanchard" <hollisb@xxxxxxxxxx>, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 23 Oct 2006 02:26:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <E4F841F0-0CFD-4A0B-A96A-0A8002E4D6AC@xxxxxxxxxxxxxx>
List-help: <mailto:xen-ppc-devel-request@lists.xensource.com?subject=help>
List-id: Xen PPC development <xen-ppc-devel.lists.xensource.com>
List-post: <mailto:xen-ppc-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ppc-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acb2f7CN71z4hWJyEdu2fwAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH] don't use mlock() with Solaris tools
User-agent: Microsoft-Entourage/11.2.5.060620
On 22/10/06 22:09, "Jimi Xenidis" <jimix@xxxxxxxxxxxxxx> wrote:

> I cannot speak for Hollis (I think he may actually disagree with me)
> but see this as an opportunity to design something better, or at
> least have the debat (again).
> What might be a better alternative an to actually have an allocate
> call rather than an mlock call where the arches and OSes could to
> what is best for them.
> So what is done on x86 could be:
>    do { x = alloca(len); mlock (x, len); } while (0)
> 
> but where solaris and other arches could do something more.

It would change the API too, since memory buffers passed in by callers to
libxc would also need to be allocated in a special way. Unless you would be
prepared to perform the hypercall on a shadow buffer and then copy to the
caller buffer, which I suppose would be a simpler API.

John's patch is fine for now.

 -- Keir



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