Re: [RFC] net-dhcp-leases: virNetworkDHCPLeases struct design

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

 



On 10/08/2013 06:39 AM, Nehal J Wani wrote:
> Continued from https://www.redhat.com/archives/libvir-list/2013-October/msg00325.html
> 

> Since no one likes the idea of having a union, but we do want to
> support dhcpv6, following is the new design:
> 
> struct _virNetworkDHCPLeases {
>     char *interface;            /* Network interface name (non-null) */
>     long long expirytime;       /* Seconds since epoch (non-null) */

(non-null) makes no sense for an integer.  On the other hand, should we
document a sentinel for unknown (or infinite) lease expiration?

>     int type;                   /* virIPAddrType (non-null) */

(non-null) makes no sense for an integer.

>     unsigned int prefix;        /* IP address prefix (non-null) */

(non-null) makes no sense for an integer; should we document that 0
means unknown?

>     char *mac;                  /* MAC address (mostly non-null,
> except rare cases) */

I guess it could be NULL for the generic virNetworkDHCPLeases query; but
I don't see how it can possibly be NULL for the specific per-MAC
virNetworkDHCPLeases ForMAC().  Probably also worth documenting that it
is in ASCII form (not raw bytes).  If you implement it as remote_string
on the RPC side, then you are guaranteeing that it is non-NULL; are we
hurting ourselves if we make that guarantee?

>     char *iaid;                 /* IAID (ipv6) (null, in case of ipv4) */
>     char *ipaddr;               /* IP address (non-null) */

Maybe mention that it is in ASCII form, not raw bytes (maybe mention
that once, at the top of the struct, since it now applies to both MAC
and IP strings).

>     char *hostname;             /* Hostname (can be null) */
>     char *clientid;             /* Client ID(ipv4) or DUID(ipv6) (can
> be null, in case of ipv4) */
> };
> 

Seems like a reasonable struct to me.  I'm not an IPv6 expert, if anyone
else wants to chime in, but it's certainly looking better for use in a
v5 series than what we were debating in v4.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
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]