[libvirt] [PATCH 2/5] First level of plumbing for virInterface*.
Daniel Veillard
veillard at redhat.com
Wed May 13 11:29:14 UTC 2009
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 at veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
More information about the libvir-list
mailing list