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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel