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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/
daniel@xxxxxxxxxxxx  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]