On Wed, Sep 06, 2006 at 03:48:43PM +0200, michel.ponceau@xxxxxxxx wrote: > I previously made a proposal for block devices. It was rejected because it > was VBD-specific and Xen-specific. Here is a proposal for transparent > interface with Xen or other. The virtual device attributes (VDA) are > transferred from/to application without considering their meaning, except > backend domain, previously requested to be the name for user, while it is > the ID for Xen. This is just exchanging a direct Xen-specific API, for an indirectly Xen-specific API. The end result is the same - applications using this API will be forced to know about & use Xen-isms when configuring new block devices. The XML used to initially create a domain manages to allow definition of block devices without using Xen-isms, so there is no reason why the same shouldn't be possible here. I also question why we need virDomainGetVdevs at all, when this information is already available from the XML provided by virDomainGetXMLDesc. Adding a new API which duplicates this info doesn't seem like a benefit to me. > int virDomainGetVdevs(virDomainPtr domain, char *type, virVDA *attr, int > maxattr); > * @type: pointer to device type, "disk", "network" ... > * @attr: pointer to an array of virVDA structures > * @maxattr: number of structures in attr array > * Return: (number of VDAs per device)<<16 + (number of devices), if > success; I question why we need virDomainGetVdevs at all, when this information is already available from the XML provided by virDomainGetXMLDesc. Adding a new API which duplicates this info doesn't seem like a benefit to me. We do need an explicit API for fetching disk I/O statstics, but that's not what's being addressed here. > int virDomainCreateVdev(virDomainPtr domain, char *type, virVDA *attr, int > nbattr); > * @type: pointer to device type, "disk", "network" ... > * @attr: pointer to an array of virVDA structures > * @nbattr: number of structures in attr array > For "disk" type, Xen requires the following VDA names: > "uname" (backend device, value either "phy:<>" or "file:<>" > "dev" (virtual device number) > "mode" (value "ro" for read-only, or "rw" for read/write) > "backend" (backend domain ID) > This function translates "backend" user value (name) into ID. Nak. This is still full of Xen-isms, and doesn't follow the API style of existing APIs. If we need to pass arbitrarily extendable metadata then XML should be used. If not then we should use strongly typed parameters, or a struct containing strongly typed parameters. > int virDomainDestroyVdev(virDomainPtr domain, char *type, char *ref); > * @type: pointer to device type, "disk", "network" ... > * @ref: pointer to virtual device reference (number for Xen...) Close, but 'ref' isn't acceptable - there is already a unique parameter for refering to devices - their device name as detailed in the 'dev' attribute of the <target> element. Using a Xen specific integer ID is wrong. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|