| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] xend leaks/bugs/etc
> > 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?
Sysfs and hotplug are the model.
> > 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.
To be fair to xend, this is what it does already: all its internal state
is stored in the file system, hence it can be killed and restarted
(modulo bugs in the current unstable).
The key step that needs to happen with the rewrite is to factor xend
into a number of pieces that communicate via the persistent store.
> > 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.
It's hard to beat python for this sort of thing...
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home