From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: Re: [PATCH RFC 00/10] libxl: new hotplug calling convention Date: Thu, 17 Jan 2013 17:45:50 +0100 Message-ID: <50F82ABE.5090301@citrix.com> References: <1356109208-6830-1-git-send-email-roger.pau@citrix.com> <1358431019.13856.69.camel@zakaz.uk.xensource.com> <50F818FA.4010001@citrix.com> <1358437204.13856.71.camel@zakaz.uk.xensource.com> <50F81CF9.1040705@citrix.com> <1358438224.13856.76.camel@zakaz.uk.xensource.com> <50F82291.1070306@citrix.com> <1358439310.13856.81.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1358439310.13856.81.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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.