[libvirt] [PATCH 2/5] First level of plumbing for virInterface*.

[Laine Stump]

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 at 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?