Re: [libvirt] [PATCH 2/5] First level of plumbing for virInterface*.
On Tue, May 19, 2009 at 12:51:24PM -0400, Laine Stump wrote: From: Laine Stump la...@redhat.com Okay, looks fine too, ACK, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/5] First level of plumbing for virInterface*.
On Tue, May 19, 2009 at 12:51:24PM -0400, Laine Stump wrote:
From: Laine Stump la...@redhat.com
---
include/libvirt/virterror.h |4 +
src/datatypes.h | 25 ++
src/driver.h| 60 +
src/libvirt.c | 607
+++
src/virterror.c | 21 ++
5 files changed, 717 insertions(+), 0 deletions(-)
diff --git a/include/libvirt/virterror.h b/include/libvirt/virterror.h
index 4677ebc..3613ac2 100644
--- a/include/libvirt/virterror.h
+++ b/include/libvirt/virterror.h
@@ -63,6 +63,7 @@ typedef enum {
VIR_FROM_XEN_INOTIFY, /* Error from xen inotify layer */
VIR_FROM_SECURITY, /* Error from security framework */
VIR_FROM_VBOX,/* Error from VirtualBox driver */
+VIR_FROM_INTERFACE, /* Error when operating on an interface */
} virErrorDomain;
@@ -158,6 +159,9 @@ typedef enum {
VIR_ERR_NO_NODE_DEVICE,/* node device not found */
VIR_ERR_NO_SECURITY_MODEL, /* security model not found */
VIR_ERR_OPERATION_INVALID, /* operation is not applicable at this time */
+VIR_WAR_NO_INTERFACE, /* failed to start interface driver */
+VIR_ERR_NO_INTERFACE, /* interface driver not running */
+VIR_ERR_INVALID_INTERFACE, /* invalid interface object */
} virErrorNumber;
/**
diff --git a/src/datatypes.h b/src/datatypes.h
index 5956c5d..756e0a5 100644
--- a/src/datatypes.h
+++ b/src/datatypes.h
@@ -59,6 +59,16 @@
#define VIR_IS_CONNECTED_NETWORK(obj)(VIR_IS_NETWORK(obj)
VIR_IS_CONNECT((obj)-conn))
/**
+ * VIR_INTERFACE_MAGIC:
+ *
+ * magic value used to protect the API when pointers to interface structures
+ * are passed down by the users.
+ */
+#define VIR_INTERFACE_MAGIC 0xDEAD5309
+#define VIR_IS_INTERFACE(obj)((obj)
(obj)-magic==VIR_INTERFACE_MAGIC)
+#define VIR_IS_CONNECTED_INTERFACE(obj) (VIR_IS_INTERFACE(obj)
VIR_IS_CONNECT((obj)-conn))
+
+/**
* VIR_STORAGE_POOL_MAGIC:
*
* magic value used to protect the API when pointers to storage pool
structures
@@ -106,6 +116,7 @@ struct _virConnect {
/* The underlying hypervisor driver and network driver. */
virDriverPtr driver;
virNetworkDriverPtr networkDriver;
+virInterfaceDriverPtr interfaceDriver;
virStorageDriverPtr storageDriver;
virDeviceMonitorPtr deviceMonitor;
@@ -115,6 +126,7 @@ struct _virConnect {
*/
void *privateData;
void *networkPrivateData;
+void *interfacePrivateData;
void *storagePrivateData;
void *devMonPrivateData;
@@ -167,6 +179,19 @@ struct _virNetwork {
};
/**
+* _virInterface:
+*
+* Internal structure associated to a physical host interface
+*/
+struct _virInterface {
+unsigned int magic; /* specific value to check */
+int refs;/* reference count */
+virConnectPtr conn; /* pointer back to the connection */
+char *name; /* the network external name */
+char *mac; /* the interface MAC address */
+};
+
+/**
* _virStoragePool:
*
* Internal structure associated to a storage pool
diff --git a/src/driver.h b/src/driver.h
index b8e0a04..01758a9 100644
--- a/src/driver.h
+++ b/src/driver.h
@@ -488,6 +488,65 @@ struct _virNetworkDriver {
virDrvNetworkSetAutostartnetworkSetAutostart;
};
+/*---*/
+typedef int
+(*virDrvNumOfInterfaces)(virConnectPtr conn);
+typedef int
+(*virDrvListInterfaces) (virConnectPtr conn,
+ char **const names,
+ int maxnames);
+typedef virInterfacePtr
+(*virDrvInterfaceLookupByName) (virConnectPtr conn,
+ const char *name);
+typedef virInterfacePtr
+(*virDrvInterfaceLookupByMACString) (virConnectPtr conn,
+ const char *mac);
+
+typedef char *
+(*virDrvInterfaceGetXMLDesc)(virInterfacePtr interface,
+ unsigned int flags);
+
+typedef virInterfacePtr
+(*virDrvInterfaceDefineXML) (virConnectPtr conn,
+ const char *xmlDesc,
+ unsigned int flags);
+typedef int
+(*virDrvInterfaceUndefine) (virInterfacePtr interface);
+typedef int
+(*virDrvInterfaceCreate)(virInterfacePtr interface,
+ unsigned int flags);
+typedef int
+(*virDrvInterfaceDestroy) (virInterfacePtr interface,
+ unsigned int flags);
+
+typedef struct _virInterfaceDriver virInterfaceDriver;
+typedef
Re: [libvirt] [PATCH 2/5] First level of plumbing for virInterface*.
On Mon, May 11, 2009 at 03:29:42PM -0400, Laine Stump wrote: On 05/11/2009 06:35 AM, Daniel P. Berrange wrote: On Fri, May 08, 2009 at 01:52:24PM -0400, Laine Stump wrote: From: Laine Stump la...@redhat.com --- include/libvirt/libvirt.h| 18 ++ include/libvirt/libvirt.h.in | 18 ++ include/libvirt/virterror.h |4 + src/datatypes.h | 25 ++ src/driver.h | 60 src/libvirt.c| 695 ++ src/util.h |2 - src/virterror.c | 21 ++ 8 files changed, 841 insertions(+), 2 deletions(-) diff --git a/include/libvirt/libvirt.h b/include/libvirt/libvirt.h index 91af6fd..b0d93a2 100644 --- a/include/libvirt/libvirt.h +++ b/include/libvirt/libvirt.h @@ -433,6 +433,24 @@ extern virConnectAuthPtr virConnectAuthPtrDefault; #define VIR_UUID_STRING_BUFLEN (36+1) +/** + * VIR_MAC_BUFLEN: + * + * This macro provides the length of the buffer required + * for an interface MAC address + */ + +#define VIR_MAC_BUFLEN (6) + +/** + * VIR_MAC_STRING_BUFLEN: + * + * This macro provides the length of the buffer required + * for virInterfaceGetMACString() + */ + +#define VIR_MAC_STRING_BUFLEN (VIR_MAC_BUFLEN * 3) + Since this is now in our public API, I'm wondering whether we shouldn't make the buflen longer. 6 bytes is fine with wired ethernet, but I'm not sure its sufficient for all network device types in general. eg, my wmaster0 device has a rather longer hardware address wmaster0 Link encap:UNSPEC HWaddr 00-13-02-B9-F9-D3-F4-1F-00-00-00-00-00-00-00-00UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Yes, tun interfaces too. Since this is binary data rather than a null-terminated string, we need to decide among the following three choices: 1) have a fixed length (how long? is 16 bytes long enough?) and zero-fill the shorter ones. 2) Add a macLen arg to any API function that uses mac address (this will need to be a return arg in some cases too) 3) Only provide the versions of the functions that accept/use ASCII mac address args. IMHO, I would play safe at this point and pick 3) First it's sufficient, from the ASCII version people can usually derive the binary one if they really need it, but mostly I think people asked for those interfaces at the libvirt level because they wanted the ability to not mess with the low level stuff, so we should focuse on the high level. And if this proves unsufficient we can stil add new APIs based on the people feedback. Also, this has ramifications on other code outside virInterface* using VIR_MAC_BUFLEN, so there will probably need to be a patch separate from this series that grows VIR_MAC_BUFLEN and fixes that other code accordingly Any opinion on how to proceed? I would go for 3) but keep the 2 macros internally either in the internals.h file or in a network header and try to make sure we use them everywhere :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/5] First level of plumbing for virInterface*.
On Wed, May 13, 2009 at 11:46:58AM +0200, Daniel Veillard wrote: On Mon, May 11, 2009 at 03:29:42PM -0400, Laine Stump wrote: Yes, tun interfaces too. Since this is binary data rather than a null-terminated string, we need to decide among the following three choices: 1) have a fixed length (how long? is 16 bytes long enough?) and zero-fill the shorter ones. 2) Add a macLen arg to any API function that uses mac address (this will need to be a return arg in some cases too) 3) Only provide the versions of the functions that accept/use ASCII mac address args. IMHO, I would play safe at this point and pick 3) First it's sufficient, from the ASCII version people can usually derive the binary one if they really need it, but mostly I think people asked for those interfaces at the libvirt level because they wanted the ability to not mess with the low level stuff, so we should focuse on the high level. And if this proves unsufficient we can stil add new APIs based on the people feedback. Ok, so we just need to get rid of the constants in the public header file, and remove these APis virInterfacePtr virInterfaceLookupByMAC (virConnectPtr conn, const unsigned char *mac); int virInterfaceGetMAC(virInterfacePtr interface, unsigned char *mac); and change the remote_protocol.x file to use 'remote_nonnull_string' instead of the fixed length mac addr on the wire. And in the virInterfacePtr struct in src/datatypes.c also use the null terminated string, instead of fixed byte array. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/5] First level of plumbing for virInterface*.
On Wed, May 13, 2009 at 10:57:13AM +0100, Daniel P. Berrange wrote: On Wed, May 13, 2009 at 11:46:58AM +0200, Daniel Veillard wrote: On Mon, May 11, 2009 at 03:29:42PM -0400, Laine Stump wrote: Yes, tun interfaces too. Since this is binary data rather than a null-terminated string, we need to decide among the following three choices: 1) have a fixed length (how long? is 16 bytes long enough?) and zero-fill the shorter ones. 2) Add a macLen arg to any API function that uses mac address (this will need to be a return arg in some cases too) 3) Only provide the versions of the functions that accept/use ASCII mac address args. IMHO, I would play safe at this point and pick 3) First it's sufficient, from the ASCII version people can usually derive the binary one if they really need it, but mostly I think people asked for those interfaces at the libvirt level because they wanted the ability to not mess with the low level stuff, so we should focuse on the high level. And if this proves unsufficient we can stil add new APIs based on the people feedback. Ok, so we just need to get rid of the constants in the public header file, and remove these APis virInterfacePtr virInterfaceLookupByMAC (virConnectPtr conn, const unsigned char *mac); int virInterfaceGetMAC(virInterfacePtr interface, unsigned char *mac); and change the remote_protocol.x file to use 'remote_nonnull_string' instead of the fixed length mac addr on the wire. And in the virInterfacePtr struct in src/datatypes.c also use the null terminated string, instead of fixed byte array. Yes I think that's the simpler, and doesn't prevent adding something to that intent later if the need arise. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/5] First level of plumbing for virInterface*.
On 05/13/2009 07:29 AM, Daniel Veillard wrote: On Wed, May 13, 2009 at 10:57:13AM +0100, Daniel P. Berrange wrote: On Wed, May 13, 2009 at 11:46:58AM +0200, Daniel Veillard wrote: On Mon, May 11, 2009 at 03:29:42PM -0400, Laine Stump wrote: Yes, tun interfaces too. Since this is binary data rather than a null-terminated string, we need to decide among the following three choices: 1) have a fixed length (how long? is 16 bytes long enough?) and zero-fill the shorter ones. 2) Add a macLen arg to any API function that uses mac address (this will need to be a return arg in some cases too) 3) Only provide the versions of the functions that accept/use ASCII mac address args. IMHO, I would play safe at this point and pick 3) First it's sufficient, from the ASCII version people can usually derive the binary one if they really need it, but mostly I think people asked for those interfaces at the libvirt level because they wanted the ability to not mess with the low level stuff, so we should focuse on the high level. And if this proves unsufficient we can stil add new APIs based on the people feedback. Ok, so we just need to get rid of the constants in the public header file, and remove these APis virInterfacePtr virInterfaceLookupByMAC (virConnectPtr conn, const unsigned char *mac); int virInterfaceGetMAC(virInterfacePtr interface, unsigned char *mac); and change the remote_protocol.x file to use 'remote_nonnull_string' instead of the fixed length mac addr on the wire. And in the virInterfacePtr struct in src/datatypes.c also use the null terminated string, instead of fixed byte array. Yes I think that's the simpler, and doesn't prevent adding something to that intent later if the need arise. Another advantage of this is that it can be done independent of fixing other uses of mac address in the code. I'm starting on this right now. (After a morning delay for a kindergarten presentation on Turkey, and another delay for a train of realtors traipsing through our house) -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/5] First level of plumbing for virInterface*.
On Fri, May 08, 2009 at 01:52:24PM -0400, Laine Stump wrote: From: Laine Stump la...@redhat.com --- include/libvirt/libvirt.h| 18 ++ include/libvirt/libvirt.h.in | 18 ++ include/libvirt/virterror.h |4 + src/datatypes.h | 25 ++ src/driver.h | 60 src/libvirt.c| 695 ++ src/util.h |2 - src/virterror.c | 21 ++ 8 files changed, 841 insertions(+), 2 deletions(-) diff --git a/include/libvirt/libvirt.h b/include/libvirt/libvirt.h index 91af6fd..b0d93a2 100644 --- a/include/libvirt/libvirt.h +++ b/include/libvirt/libvirt.h @@ -433,6 +433,24 @@ extern virConnectAuthPtr virConnectAuthPtrDefault; #define VIR_UUID_STRING_BUFLEN (36+1) +/** + * VIR_MAC_BUFLEN: + * + * This macro provides the length of the buffer required + * for an interface MAC address + */ + +#define VIR_MAC_BUFLEN (6) + +/** + * VIR_MAC_STRING_BUFLEN: + * + * This macro provides the length of the buffer required + * for virInterfaceGetMACString() + */ + +#define VIR_MAC_STRING_BUFLEN (VIR_MAC_BUFLEN * 3) + Since this is now in our public API, I'm wondering whether we shouldn't make the buflen longer. 6 bytes is fine with wired ethernet, but I'm not sure its sufficient for all network device types in general. eg, my wmaster0 device has a rather longer hardware address wmaster0 Link encap:UNSPEC HWaddr 00-13-02-B9-F9-D3-F4-1F-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/5] First level of plumbing for virInterface*.
On 05/11/2009 06:35 AM, Daniel P. Berrange wrote: On Fri, May 08, 2009 at 01:52:24PM -0400, Laine Stump wrote: From: Laine Stump la...@redhat.com --- include/libvirt/libvirt.h| 18 ++ include/libvirt/libvirt.h.in | 18 ++ include/libvirt/virterror.h |4 + src/datatypes.h | 25 ++ src/driver.h | 60 src/libvirt.c| 695 ++ src/util.h |2 - src/virterror.c | 21 ++ 8 files changed, 841 insertions(+), 2 deletions(-) diff --git a/include/libvirt/libvirt.h b/include/libvirt/libvirt.h index 91af6fd..b0d93a2 100644 --- a/include/libvirt/libvirt.h +++ b/include/libvirt/libvirt.h @@ -433,6 +433,24 @@ extern virConnectAuthPtr virConnectAuthPtrDefault; #define VIR_UUID_STRING_BUFLEN (36+1) +/** + * VIR_MAC_BUFLEN: + * + * This macro provides the length of the buffer required + * for an interface MAC address + */ + +#define VIR_MAC_BUFLEN (6) + +/** + * VIR_MAC_STRING_BUFLEN: + * + * This macro provides the length of the buffer required + * for virInterfaceGetMACString() + */ + +#define VIR_MAC_STRING_BUFLEN (VIR_MAC_BUFLEN * 3) + Since this is now in our public API, I'm wondering whether we shouldn't make the buflen longer. 6 bytes is fine with wired ethernet, but I'm not sure its sufficient for all network device types in general. eg, my wmaster0 device has a rather longer hardware address wmaster0 Link encap:UNSPEC HWaddr 00-13-02-B9-F9-D3-F4-1F-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Yes, tun interfaces too. Since this is binary data rather than a null-terminated string, we need to decide among the following three choices: 1) have a fixed length (how long? is 16 bytes long enough?) and zero-fill the shorter ones. 2) Add a macLen arg to any API function that uses mac address (this will need to be a return arg in some cases too) 3) Only provide the versions of the functions that accept/use ASCII mac address args. Also, this has ramifications on other code outside virInterface* using VIR_MAC_BUFLEN, so there will probably need to be a patch separate from this series that grows VIR_MAC_BUFLEN and fixes that other code accordingly Any opinion on how to proceed? -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
