Re: [Xen-devel] [PATCH 28 of 29 RFC] libxl: add libxl__find_free_vdev

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

2012/2/9 Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 28 of 29 RFC] libxl: add 
> libxl__find_free_vdev"):
>> libxl: add libxl__find_free_vdev
>>
>> Add a function that returns the first free xvd<x> device, used to
>> attach a DomU image and execute the bootloader against that.
>
> I'm afraid I don't understand the purpose of this at all.

The main purpose of this series is to separate the control code from
the device code (make xl able to plug devices from a domain different
than dom0). Since the root image might not be stored on the dom0, we
need to be able to make this image available to the dom0 somehow, to
extract the kernel and ramdisk. One option is to execute pygrub from
the device domain, the other option is to plug the domU hard drive to
the dom0, run the bootloader to extract the kernel/initrd and unplug
the hd.

The later is the one implemented here partially, since
libxl_device_disk_local_attach still doesn't call the driver domain to
attach the device, this is done on a later patch (yes, it's probably a
mess).

> Also the comment "add <some function>" is not accurate because the
> real change is to run the bootloader on some other disk.

Not really, the bootloader was currently run against the vbd/phy
partition currently (eg: pygrub /home/xen/disk.img), not against the
vdev of the hd, because the hd was never locally attached
(libxl_device_disk_local_attach just returned the path to the phy
partition or vbd image, but never attached it to the dom0).

Following changes in this series make libxl_device_disk_local_attach
honor it's name, and truly attach the device to the dom0, creating a
new vdev in the dom0. Since the user might be using vdevs (xvda,
xvdb...) for it's own purposes, we need to find a free vdev in the
dom0 and attach the vbd to that, that's why this function is needed.

Hope this is clarifies things a little bit, and sorry for the delay.

Regards, Roger.

> Ian.

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