|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 00/10] libxl: new hotplug calling convention
On 17/01/13 16:57, Ian Campbell wrote: > On Thu, 2013-01-17 at 15:47 +0000, Roger Pau Monne wrote: >> On 17/01/13 16:40, Ian Campbell wrote: >>> On Thu, 2013-01-17 at 15:30 +0000, Roger Pau Monne wrote: >>>> We still need pdev_path, I would say only internally because once the >>>> "target" has been attached to the Dom0, pdev_path has the path to the >>>> block device that will be used in blkback, but the caller doesn't need >>>> to know about this. >>> >>> So in the new scheme both pdev_path are valid and contain different >>> information? >> >> Yes, target would be what's passed by the user, like: >> >> "iqn=iqn.1994-04.org.netbsd.iscsi-target:target0,portal=192.168.1.128" >> >> And pdev_path would be filled after the device has been attached, and it >> will be something like: >> >> /dev/sdb > > I see. When we login and create /dev/sdb we can't overwrite target? Or > move pdev_path into some purely internal datastructure? Yes that's another option, what I'm doing in this series is overwriting pdev_path, we could just change the name of pdev_path to target (with a union as you said) and keep doing it (overwriting target with the physical path of the attached device). I'm afraid there's no internal disk related structure, only libxl_device_disk (public) or libxl__device, but libxl__device is too general, and I don't want to start overloading it with disk specific values. > >> The main reason we need the block device is to be able to call pygrub or >> to pass it to Qemu. > > I see. > > Ian. > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |