On 11/24/2014 04:23 PM, John Ferlan wrote:
>
> On 11/24/2014 12:48 PM, Laine Stump wrote:
>> + if (nlmsg_append(nl_msg, &ndm, sizeof(ndm), NLMSG_ALIGNTO) < 0)
>> + goto buffer_too_small;
>> + if (nla_put(nl_msg, NDA_LLADDR, VIR_MAC_BUFLEN, mac) < 0)
>> + goto buffer_too_small;
> So if someone adds the same thing twice, what happens? Does it matter?
> IOW: Is there any need for us to check a return status here that
> indicates "duplicate entry" and ignore? Or is there any need for a
> *FDBGet() function to determine whether what we're about to add already
> exists?
If you try to add something that's already there, or remove something
that isn't there, the kernel returns an error. We're only adding these
entries immediately after creating a tap device, so the entry will never
exist, and we actually never delete anything - it's automatically
deleted when the tap device is deleted.
In the future when we allow changing MAC address, then we'll need to
think about those things, but for now we're safe.
The "FDBGet()" type function is considerably more complicated (you
basically get a dump of the entire db into a list), and not needed for
what I'm implementing now.
>
> Similar argument of course for delete, but removing something that
> doesn't exist - what happens?
>
> Then course there's the "FDBModify()" type function. We have something,
> but want to change a setting.
That really never happens. You add them and take them away.
>
>> + return -1;
>> +}
>> +
>> +
>> +#endif
>> +
>> +int
>> +virNetDevBridgeFDBAdd(const virMacAddr *mac, const char *ifname,
>> + unsigned int flags)
>> +{
>> + return virNetDevBridgeFDBAddDel(mac, ifname, flags, true);
>> +}
>> +
>> +
> Thinking out loud for the future patches. The 'flags' here - must they
> match how they were added?
I think they do matter, as it's possible to have two entries with the
same MAC address and interface name, but different flags.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list