Xen Store Release

Xen Store Release

[Rusty Russell]

OK, a new version of the Xen Store daemon is up:

	rsync -av ozlabs.org::rusty/xenstore .

This version has the first cut of an xs_introduce_domain() call for
tools to tell the daemon about new domains: the transport is a pair of
simple ringbuffers within a shared page, and an event channel for change
notifications.  There's no xs_disconnect_domain() yet, but it's fairly
trivial to implement.

The code has been tested in userspace: next step is to change the tools
to actually make the call (Mike and Anthony) and create a XenBus layer
to make it easy for drivers to talk to the Xen daemon (my next task).

Feedback welcome!
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

Re: Xen Store Release

[Mike Wray]

Rusty Russell wrote:
> OK, a new version of the Xen Store daemon is up:
> 
> 	rsync -av ozlabs.org::rusty/xenstore .
> 
> This version has the first cut of an xs_introduce_domain() call for
> tools to tell the daemon about new domains: the transport is a pair of
> simple ringbuffers within a shared page, and an event channel for change
> notifications.  There's no xs_disconnect_domain() yet, but it's fairly
> trivial to implement.
> 
> The code has been tested in userspace: next step is to change the tools
> to actually make the call (Mike and Anthony) and create a XenBus layer
> to make it easy for drivers to talk to the Xen daemon (my next task).

I've just written a Python module wrapping the xs client interface
and checked it in to CVS on gandalf.

I added a library target to xenstore for the Python module to link,
and made it possible to configure the paths it uses from the env.

The module is called 'xen.xs' and lives in xspy in CVS top-level for now.

BTW, using it I came across this slightly weird behaviour:

 >>> import xen.xs
 >>> h = xen.xs.open()
 >>> h.write("/foo", "hello", create=1)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
RuntimeError: (21, 'Is a directory')
 >>> h.ls("/")
['./', '../', 'foo/', '.perms', 'foo.perms']

Write to /foo failed beacuse it's a dir - expected.
But listing / showed  foo as expected, plus
'./', '../', '.perms', 'foo.perms'.

The daemon should probably filter out '.', '..' and its internal
'.perms' files from the results.

 >>> h.get("/.perms")
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
AttributeError: get
 >>> h.get("/foo.perms")
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
AttributeError: get

> 
> Feedback welcome!
> Rusty.

Mike

Re: Xen Store Release

[Mike Wray]

Rusty Russell wrote:
> OK, a new version of the Xen Store daemon is up:
> 
> 	rsync -av ozlabs.org::rusty/xenstore .
> 
> This version has the first cut of an xs_introduce_domain() call for
> tools to tell the daemon about new domains: the transport is a pair of
> simple ringbuffers within a shared page, and an event channel for change
> notifications.  There's no xs_disconnect_domain() yet, but it's fairly
> trivial to implement.
> 
> The code has been tested in userspace: next step is to change the tools
> to actually make the call (Mike and Anthony) and create a XenBus layer
> to make it easy for drivers to talk to the Xen daemon (my next task).
> 
> Feedback welcome!

Excellent.

I think the time has come to put xenstore and the Python wrapper into the
xen tree so they all get built together.

I suggest moving the daemon into tools/xenstore and the python wrapper
into tools/python/xen/lowlevel/xs (alongside xc and xu).
If no-one screams I'll move them.

Mike

Re: Re: Xen Store Release

[Daniel Stekloff]

[-- Attachment #1: Type: text/plain, Size: 213 bytes --]


There's a typo in the CVS xenstore Makefile....

Also. Shouldn't libxs.a be installed somewhere? There's elements in
xeno-unstable module that depend upon it.

Thanks,

Dan


Signed-off-by: dsteklof@us.ibm.com



[-- Attachment #2: xenstore-fix-Makefile.patch --]
[-- Type: text/x-patch, Size: 369 bytes --]

--- xen-ctrltools-cvs/xenstore/Makefile	2005-05-13 05:59:50.000000000 -0700
+++ xen-ctrltools-cvs-test/xenstore/Makefile	2005-05-13 10:06:07.000000000 -0700
@@ -60,6 +60,6 @@
 	mkdir /var/lib/xsdaemon
 	mkdir /var/lib/xsdaemon/store
 	mkdir /var/lib/xsdaemon/transactions
-	cp xs_daemon /usr/local/bin
+	cp xsdaemon /usr/local/bin
 
 stdrusty.a: stdrusty.a(stdrusty.o)

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: Re: Xen Store Release

[Mike Wray]

Daniel Stekloff wrote:
> There's a typo in the CVS xenstore Makefile....
> 
> Also. Shouldn't libxs.a be installed somewhere? There's elements in
> xeno-unstable module that depend upon it.

Yeah, I know, I've got fixes but haven't committed them yet.
Bear in mind this is bleeding edge code - it's under active
development and is quite likely to be seriously broken.
That's why we took the branch.

Anyway, thanks for the patch.

Mike

Re: Re: Xen Store Release

[Mike Wray]

I've copied the xenstore code and the xs python wrapper into
the xeno-unstable tree in CVS. They're in tools/xenstore and
tools/python/xen/lowlevel/xs. I adjusted the xenstore
makefile to fit with the xen makefiles.

There was a problem (apparently with TARGET_ARCH) when
I included tools/Rules.mk (which defines where the xen
libs are), so I've commented it out for now.

Mike

Re: Xen Store Release

[Rusty Russell]

On Fri, 2005-05-13 at 13:03 +0100, Mike Wray wrote:
>  >>> h.write("/foo", "hello", create=1)
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
> RuntimeError: (21, 'Is a directory')
>  >>> h.ls("/")
> ['./', '../', 'foo/', '.perms', 'foo.perms']

This is horribly broken!  There's no way this would have passed the
testsuite.  The only thing I can think of is, did you try to add "." to
the valid characters array?  That won't work...

Thanks!
Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

Re: Xen Store Release

[Mike Wray]

Rusty Russell wrote:
> On Fri, 2005-05-13 at 13:03 +0100, Mike Wray wrote:
> 
>> >>> h.write("/foo", "hello", create=1)
>>Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>>RuntimeError: (21, 'Is a directory')
>> >>> h.ls("/")
>>['./', '../', 'foo/', '.perms', 'foo.perms']
> 
> 
> This is horribly broken!  There's no way this would have passed the
> testsuite.  The only thing I can think of is, did you try to add "." to
> the valid characters array?  That won't work...

You're right - my fault. Needs some more name filtering to allow that I guess.
Will fix.

Mike