Xen devel - Apr 2005 - A simple XenBus Daemon prototype.

Hi all,

	I''ve been working on the storage and daemon for maintaining device and
machine state for Xen.  Based somewhat loosely on designs by Mike Wray
and Anthony Liguori, as well as comments from Kier Fraser, it is now at
0.1 stage.  It''s not actually useful yet, however.

TODO:
        1) Various tweaks Mike Wray asked for: more valid chars in
        nodenames and ability to treat nodes/directories as
        interchangable.
        2) Add new fields in the start_info_t which new domains can use
        to talk to the daemon, have the domain builder tell the XenBus
        Daemon about them.
        3) Transactions
        4) More tests in the testsuite
        5) Other bugfixes.

For the moment, while it''s not integrated with Xen, I''ve use
bzr
(http://bazaar-ng.org ), but you can download and test ths source
without needing to use it.

Download the source via rsync:

	rsync -avz ozlabs.org::rusty/xenbus-daemon .

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


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

On 29 Apr 2005, at 07:52, Rusty Russell wrote:
> Hi all,
>
> 	I''ve been working on the storage and daemon for maintaining
device and
> machine state for Xen.  Based somewhat loosely on designs by Mike Wray
> and Anthony Liguori, as well as comments from Kier Fraser, it is now at
> 0.1 stage.  It''s not actually useful yet, however.
Generally looking good. I have one kind of trivial comment, which is 
that calling it ''xenbus daemon'' makes no sense. It''s
a registry daemon,
or a store daemon, or something like that, but it sure doesn''t look 
like a bus to me. :-)

I know there''s confusion about what xenbus is actually intended to be. 
The way we''ve envisaged it in Cambridge is that it is just a convenient
virtual bus abstraction within each guest OS. For example, Linux will 
have a xenbus driver that reads device state out of the repository 
(perhaps making use of a lower-level repository-access driver), and 
then presents the devices in sysfs and provides a neat interface for 
the specific drivers (blk, net, usb, whatever) to connect to the 
appropriate backend driver domain.

It was never our intention for the concept of a ''xenbus'' to
leak
outside individual guest OSes and into the user-space control tools. 
The old xr (xen registry) naming scheme was just fine imo.

  -- Keir


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