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 <laine(a)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?