From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Fioravante Subject: Re: [PATCH xm/xl enhancements for vptm 5/6] make devid a libxl type Date: Tue, 25 Sep 2012 12:00:43 -0400 Message-ID: <5061D52B.9080503@jhuapl.edu> References: <505CBDFD.5070408@jhuapl.edu> <1348569397.3452.180.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5528710076050718605==" Return-path: In-Reply-To: <1348569397.3452.180.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.xensource.com" List-Id: xen-devel@lists.xenproject.org This is a cryptographically signed message in MIME format. --===============5528710076050718605== Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000803050900070401010201" This is a cryptographically signed message in MIME format. --------------ms000803050900070401010201 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/25/2012 06:36 AM, Ian Campbell wrote: > On Fri, 2012-09-21 at 20:20 +0100, Matthew Fioravante wrote: >> This fixes a bug in libxl where device ids are not initialized properl= y. >> The devid field for each device is set to be an integer type which are= >> always initialized to 0. >> >> This makes the xl DEV-attach commands always fail to add more than one= >> device, because each time the device id is initialized to 0, when it >> should be initialized to -1, which in the code will trigger a search f= or >> free id. > Which of the DEV-attach commands can be used to add more than one > device? network-attach, block-attach, and also my vtpm-attach. > > Where is the code to do the search? I had a look in the disk and networ= k > cases and couldn't find it. libxl.c void libxl__device_nic_add( if (nic->devid =3D=3D -1) { if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) { rc =3D ERROR_FAIL; goto out_free; } if (!(l =3D libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) { nic->devid =3D 0; } else { nic->devid =3D strtoul(l[nb - 1], NULL, 10) + 1; } } Right now, nic-devid is 0 on attach. So it always tries to use 0. When you do a network-attach twice, the second time it trys and fails to create device/vif/0 > >> diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli >> --- a/tools/ocaml/libs/xs/xs.mli >> +++ b/tools/ocaml/libs/xs/xs.mli >> @@ -27,6 +27,7 @@ exception Failed_to_connect >> type perms =3D Xsraw.perms >> =20 >> type domid =3D int >> +type devid =3D int > I can see why these were needed in the xl modules, but I don't see how > this type can be required in the xenstore ones. It shouldn't be required for xenstore or xc. The problem is they won't compile without it because of the way the ocaml build system works. As far as I understand it creates types for xl, xc, and xs from the libxl_types.idl. Either the build system needs to be changed, or devid needs to be a type in all libraries, or we find some other way to fix this initialization bug. > > Ian. > --------------ms000803050900070401010201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4 NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50 ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz 4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMDkyNTE2MDA0M1owIwYJKoZIhvcNAQkEMRYEFPGyyfcYJSN7cjuH jSgPNrb4sfPZMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCRFD2yVDs8bH4sJzHLGZ5R4aDZUjmMv4N0 +sOGlfj1XHMrItpa8q0PMB4Kd1KCiegE24S+3T0PGQbcjSyIBp83QvkyBKng329soaDKJyrb +zCqtMH4fHdFC9DcwVQEuR7X9A9LS/BTAP0qfFflU1cUSBKdJP545z4NTRFco7pOuAAAAAAA AA== --------------ms000803050900070401010201-- --===============5528710076050718605== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5528710076050718605==--