[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |