similar to: [Fwd: [Xen-changelog] Move xcs to unix domain sockets.]

Hello, I''m trying to get PDB working in accordance with the instructions at http://www.cl.cam.ac.uk/~sos22/replay.bk/docs/misc/XenDebugger-HOWTO and a message from this list: http://lists.xensource.com/archives/html/xen-devel/2004-08/msg00017.html When I try to build pdb I first get errors because the Makefile is configured to treat warnings as errors, and there are some warnings.

Currently xcs is run by xend in xen-unstable by simply making it a child process. If you launch xend from an ssh session, the session won''t exit because the xcs still is connected to it''s controlling terminal. xcs should daemonize itself to prevent this from happening. This patch does that along with making the domain id => port mapping dynamically allocated. Regards, --

On Fri, 25 Feb 2005, BitKeeper Bot wrote: > ChangeSet 1.1265, 2005/02/25 22:55:44+00:00, akw27@arcadians.cl.cam.ac.uk > diff -Nru a/tools/misc/xend b/tools/misc/xend > --- a/tools/misc/xend 2005-02-26 06:03:12 -05:00 > +++ b/tools/misc/xend 2005-02-26 06:03:12 -05:00 > @@ -24,7 +24,7 @@ > import socket > import time > > -XCS_PORT = 1633 > +XCS_PATH =

Xen patchbot -unstable wrote: ># HG changeset patch ># User cl349@firebug.cl.cam.ac.uk ># Node ID 8fe8a99b1c2a6ea88624546ab625eaa0758e3a17 ># Parent e69cbfee4011da1648718f1f5cbe8dabb956e72a >New console transport and update xenconsoled. >Add a new console interface using a seperate shared page and event channel >instead of passing the console input/output over control

Hi, Is there some easy way to install both 2.x and unstable xen tools at the same machine? Seems /usr is hardcoded everythere in the tools Makefiles, looks like there is no easy way to put them to different paths (say, prefix /opt/xen2 and /opt/xen3) :-/ Gerd _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

In-Reply-To: <20060803002518.190834642@xensource.com> On Wed, 02 Aug 2006 17:25:13 -0700, Jeremy Fitzhardinge wrote: > We allow for the fact that the guest kernel may not run in ring 0. > This requires some abstraction in a few places when setting %cs or > checking privilege level (user vs kernel). I made some changes: a. Added some comments about the SEGMENT_IS_*_CODE() macros.

In-Reply-To: <20060803002518.190834642@xensource.com> On Wed, 02 Aug 2006 17:25:13 -0700, Jeremy Fitzhardinge wrote: > We allow for the fact that the guest kernel may not run in ring 0. > This requires some abstraction in a few places when setting %cs or > checking privilege level (user vs kernel). I made some changes: a. Added some comments about the SEGMENT_IS_*_CODE() macros.

Introduce a write acessor for updating the current LDT. This is required for hypervisors like Xen that do not allow LDT pages to be directly written. Testing - here's a fun little LDT test that can be trivially modified to test limits as well. /* * Copyright (c) 2005, Zachary Amsden (zach@vmware.com) * This is licensed under the GPL. */ #include <stdio.h> #include <signal.h>

Introduce a write acessor for updating the current LDT. This is required for hypervisors like Xen that do not allow LDT pages to be directly written. Testing - here's a fun little LDT test that can be trivially modified to test limits as well. /* * Copyright (c) 2005, Zachary Amsden (zach@vmware.com) * This is licensed under the GPL. */ #include <stdio.h> #include <signal.h>

Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. The main change from the last posting is that all the page-table related patches have been moved out, and will be posted separately. Also, the off-by-one in reserving the top of address space has been

Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. The main change from the last posting is that all the page-table related patches have been moved out, and will be posted separately. Also, the off-by-one in reserving the top of address space has been

[ REPOST: Apologies to anyone who has seen this before. It didn't make it onto any of the lists it should have. -J ] Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. For the most part, these patches do nothing or very little. The patches should

[ REPOST: Apologies to anyone who has seen this before. It didn't make it onto any of the lists it should have. -J ] Hi Andrew, This series of patches lays the basic ground work for the paravirtualized kernel patches coming later on. I think this lot is ready for the rough-and-tumble world of the -mm tree. For the most part, these patches do nothing or very little. The patches should

libxutil is not build and installed by default, so "Makefile uninstall" will not try to remove it. This patch is against -unstable, ChangeSet@1.1575 Signed-off-by: Nguyen Anh Quynh <aquynh@gmail.com> ===== Makefile 1.94 vs edited ===== --- 1.94/Makefile 2005-05-25 03:54:03 +09:00 +++ edited/Makefile 2005-05-28 02:09:46 +09:00 @@ -160,7 +160,7 @@ uninstall: [ -d

I''ve been working on a xen-unstable tree from mid-April. I wanted to upgrade to the latest version, so here is what I did: - Clone a fresh copy of xeno-unstable.bk (1.1507) - "make world" - Change the .config of linux-2.6.11-xen0 to include my ethernet card (CONFIG_FORCEDETH=y) - Add localversion files to linux-2.6.11-xen0 and linux-2.6.11-xenU - rm -rf the existing dist

When forwarding a Unix-domain socket, the remote socket path must be absolute (otherwise the forwarding fails later). However, guessing absolute path on the remote end is sometimes not straightforward, because the file system location may vary for many reasons, including the system installation, the choices of NFS mount points, or the remote user ID. To allow ssh clients to request remote socket

Hi, I just installed xen 3.0.0 on a Xeon machine and it gives this error when I try to start xend. This same build has worked on other systems before. Can someone throw some light on this. I am operating as root Thanks - Pak [root@dnasim2 ~]# xend start Traceback (most recent call last): File "/usr/sbin/xend", line 111, in ? sys.exit(main()) File

--- channels.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/channels.c b/channels.c index a84b487..396e192 100644 --- a/channels.c +++ b/channels.c @@ -3014,10 +3014,14 @@ channel_setup_fwd_listener_streamlocal(int type, struct Forward *fwd, debug3("%s: type %d path %s", __func__, type, fwd->listen_path); + /* Expand home directory if necessary */ +

Hi all, I've been looking at finding common ground between the VMI, Xen and other paravirtualization approaches, and after some discussion, we're getting somewhere. These first two patches are the fundamentals, stolen mainly from the VMI patches: removing assumptions about the kernel running in ring 0, and macro-izing all the obvious para-virtualize-needing insns. The third patch is

Hi all, I've been looking at finding common ground between the VMI, Xen and other paravirtualization approaches, and after some discussion, we're getting somewhere. These first two patches are the fundamentals, stolen mainly from the VMI patches: removing assumptions about the kernel running in ring 0, and macro-izing all the obvious para-virtualize-needing insns. The third patch is