[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xend leaks/bugs/etc



On Mon, 2005-04-18 at 10:15 -0500, Anthony Liguori wrote:
> >3) Define a dynamic resource discovery mechanism for use, for example,
> >by FE and BE driver domains.  This mechanism probably ought to be a
> >service accessible over the inter-domain communication API.
> >  
> >
> I believe this is the purpose of xenbus.

Is there a design proposal for xenbus interaction with userland or
should we assume it is modeled on the linux driver core/sysfs
and /sbin/hotplug?

> I agree with all three points.  What I would like to see, and what I am 
> working on now for VM-Tools, is the function of Xend broken up.

I agree. Persistent state for domains should be kept in a file system
backed by persistent media, not in the memory of the daemon. With a
repository factored out of the daemon, the only required functions of
the daemon are to maintain control channels and to dispatch state change
notifications to the repository. Everything else can be done using
single purpose tools. 

> I think the goal should be to have the least amount of code (regardless 
> of language) in whatever is running as a daemon.

Exactly - the least amount of code that meets functional requirements. 

Mike
-- 
Mike D. Day
STSM and Architect, Open Virtualization
IBM Linux Technology Center
3039 Cornwallis Road
Research Triangle Park, NC  27709
Phone: (919) 543-4283
ncmike@xxxxxxxxxx


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.