Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 8 Feb 2012, Ian Jackson wrote:
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mtu
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/model
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/mac
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ip
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/bridge
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/ifname
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/script
> > /hotplug/<backend_domid>/<frontend_domid>/vif/<devid>/nictype
> > 
> > This will allow us to pass the libxl_device_disk and libxl_device_nic
> > struct from Dom0 to driver domain, and execute the necessary backends
> > there.
> 
> Is this really the best encoding of this information in xenstore ?
> 
> If we're allowed to assume that the backendd is a libxl program too,
> and of a reasonably similar version, perhaps we should have some kind
> of idl-generated mapping from xenstore keys to struct members ?

You have a point, however using the same encoding has two advantages:

- it is well understood and lots of lines of code have been written in many
toolstacks to support it;

- we can reuse the "state" based mechanism to establish a connection:
again not a great protocol, but very well known and understood.

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