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

[Roger Pau Monnà <roger.pau@xxxxxxxxxxxxx>]

2012/2/8 Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce 
> libxl hotplug public API functions"):
>> libxl: introduce libxl hotplug public API functions
>>
>> These functions mimic the name used by the local device functions,
>> following the nomenclature:
>
> I think these should be private functions. ÂYour new device daemon is,
> I think, part of the implementation of libxl, not something that
> another toolstack on top of libxl will reasonably want to replace.
>
> This is a new departure for libxl, which doesn't currently have any
> internal executables.

Not sure about the best approach here, I though that xldeviced will be
like xl, but that's something we can discuss about. As you can see,
the code in xldeviced is minimal, and I'm not sure if we shouldn't
allow people to make use of this new interface to develop a custom
xldeviced. It will provide much more flexibility than hotplug scripts.

>
>> The xenstore structure used by vbd disk entries:
>>
>> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>
>> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/pdev_path
>> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/vdev
>> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/script
>> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/removable
>> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/readwrite
>> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/is_cdrom
>> /hotplug/<backend_domid>/<frontend_domid>/vbd/<devid>/state
>>
>> and vif devices use the following:
>>
>> /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 ?

I've just cloned the current protocol used for the backend/frontend
devices, I have to say I don't dislike it (apart from the fact that it
is not documented), it's easy to view what we are doing, and to debug
it.

> 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 ?

Will look into it, currently neither libxl_device_disk or
libxl_device_nic don't have mappings to it's related xenstore
frontend/backend entries, it might be good to add those too first.

> Ian.

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