On Mon, May 11, 2009 at 05:35:36PM +0200, Pritesh Kothari wrote:
- If the user gives a URI with a vbox:/// prefix, we should always
handle it, unless a 'server' is set when we leave it to the remote
driver
- If an invalid path is given we must give back a real error code
- If
On Fri, May 08, 2009 at 05:42:07PM +0100, Daniel P. Berrange wrote:
The patches we just applied for the VirtualBox open method still were
not quite right. It would return VIR_DRV_OPEN_DECLINED when uri==NULL,
but before doing so it would have set conn-uri to vbox:///session. So
even though
On Fri, May 08, 2009 at 05:42:07PM +0100, Daniel P. Berrange wrote:
The patches we just applied for the VirtualBox open method still were
not quite right. It would return VIR_DRV_OPEN_DECLINED when uri==NULL,
but before doing so it would have set conn-uri to vbox:///session. So
even though
On Mon, May 11, 2009 at 04:27:36PM +0200, Daniel Veillard wrote:
On Fri, May 08, 2009 at 05:42:07PM +0100, Daniel P. Berrange wrote:
[...]
+if (conn-uri == NULL ||
+conn-uri-scheme == NULL ||
+STRNEQ (conn-uri-scheme, vbox) ||
+conn-uri-server != NULL)
+
- If the user gives a URI with a vbox:/// prefix, we should always
handle it, unless a 'server' is set when we leave it to the remote
driver
- If an invalid path is given we must give back a real error code
- If after deciding the URI is for us, any initialization fails
we must
The patches we just applied for the VirtualBox open method still were
not quite right. It would return VIR_DRV_OPEN_DECLINED when uri==NULL,
but before doing so it would have set conn-uri to vbox:///session. So
even though it declined the connection, all the later drivers would now
ignore it.
