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

[Xen-devel] Easy user-space usage of xenstore

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Easy user-space usage of xenstore
From: Rian Hunter <rian@xxxxxxx>
Date: Thu, 29 Jun 2006 16:31:55 -0400
Delivery-date: Fri, 30 Jun 2006 03:21:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi,

I want to write a Xen-aware application but I am encountering some
problems. For my applications to be Xen aware, the ones that are running
in non domain 0 need to be able to obtain some bootstrap information
from the program running in domain 0. This is very petty information (as
most IPC will be done using TCP/IP).

Basically my approach was this:

1. Process in domain-0 writes a key to /local/domain/<DomID>.  (<DomID>
refers to the domain id number assigned to a newly created vm)
2. Process in unprivileged domain reads from /local/domain/<DomID>

Of course you can see my problem: The unprivileged domain has no idea
which /local/domain/<DomID> is his! My first question: Is there a way
for an unprivileged domain to find out his <DomID> in user-space?

My second approached when I ran into this problem was:

1. Process in domain-0 writes a key to /local/domain/<DomID>.
2. Kernel-space driver in the unprivileged domain reads this value (or
watches this key) using the xs_* functions (which i believe already
defaults to the unprivileged domain's home name-space) and exposes a
character device (/dev/my_program_info) which prints out this
information.
3. Process in unprivileged domain just reads /dev/my_program_info

This second solution is too messy though! I believe I can still take the
first approach especially since the xs_* calls in the kernel default to
the home name-space. Why can't there be a user-space method to do this?

Any help would be greatly appreciated, Thank You!

Rian Hunter


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

<Prev in Thread] Current Thread [Next in Thread>