From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: ocaml libxl bindings and KeyedUnion Date: Tue, 24 Mar 2015 13:18:27 +0100 Message-ID: <20150324121827.GB17175@aepfle.de> References: <20150320081027.GA20008@aepfle.de> <1426843539.21742.92.camel@citrix.com> <20150320164417.GA23886@aepfle.de> <1426870866.21742.224.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1426870866.21742.224.camel@citrix.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 Fri, Mar 20, Ian Campbell wrote: > On Fri, 2015-03-20 at 17:44 +0100, Olaf Hering wrote: > > + ("dev", Struct(None, [("m", libxl_vscsi_hctl)])), > > + ("wwn", Struct(None, [("m", string)])), > > + ("hctl", Struct(None, [("m", libxl_vscsi_hctl)])), > > > > Aside: What is the difference between dev and hctl in this context? > > > > Its supposed to represent either "/dev/something" and "h:ct:l". > > So shouldn't dev by a string then? No, the result will be written to the "p-dev" property. > > The > > result in the "p-dev" property, which is used by the backend, is the > > same. But translating "p-dev" back into the config string for the > > scsi-list command needs some way to represent that. I'm not fully happy > > with the current way. Perhaps the code should just reuse the "p-devname" > > property to tell what was in the config file. > > Perhaps the list command should just list the canonical name for the > device (i.e p-dev? a h:c:t:l tuple) and not worry about matching the > config file? I will think about this suggestion. Right now the scsilist command does just what xm did. > I'd even go as far as suggesting that the libxl API ought only to deal > with the canonical name and that the toolstack can parse whatever forms > it likes into that (perhaps using a helper from libxlu). That would make > the libxl interface a lot simpler, wouldn't it? Olaf