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

Laine Stump laine at laine.org
Wed May 13 15:20:47 UTC 2009

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)

More information about the libvir-list mailing list