Re: [PATCH RFC 00/10] libxl: new hotplug calling convention

["Roger Pau Monné" <roger.pau@citrix.com>]

On 17/01/13 17:15, Ian Campbell wrote:
> On Thu, 2013-01-17 at 16:10 +0000, Roger Pau Monne wrote:
>> 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.
> 
> You could add such an internal struct?

Yes, will try to come up with something that's not too disruptive. I was
wrong regarding when we need to modify the pdev_path value, we only need
to modify it when booting HVM guests (see patch 08), for pygrub we use
the local attach mechanism that already has a related struct with a
field to store the physical path.