On Thu, Jun 11, 2009 at 10:28:48PM +0000 David Lutterkort wrote: > On Wed, 2009-06-10 at 11:30 +0200, Jonas Eriksson wrote: > > However, a problem may arise when multiple top-level interfaces > > share mac addresses, as drv_lookup_by_mac_string only may return > > one struct netcf_if *. This can occurr when using vlan > > interfaces, e.g. eth0.2 and eth0.3, or if vlan ifs are not to be > > considered top-level interfaces, the bridges or bonds that these > > interfaces are a part of. I therefore recommend a switch to a > > drv_list_interfaces-prototype for drv_lookup_by_mac_string. > > Yes, you are right .. it's a mess. So far I only had situations like a > bridge and an enslaved physical NIC sharing a MAC address, and I made > sure that the bridge, not the enslaved NIC is returned when you ask for > an interface by NIC. > > > For reference: > > int drv_list_interfaces(struct netcf *ncf, int maxnames, char **names); > > You are right - we need a slightly more complicated interface to cover > those cases, something like > > int ncf_lookup_by_mac_string(struct netcf *, const char *mac, int > maxifs, struct netcf_if **interfaces); > > where the return value gives the total number of toplevel interfaces > that match the given MAC, the (randomly) first MAXIFS many are returned > in INTERFACES. Does that sound better ?
That should work fine, and seems coherent with other API functions sharing the same design. I'm all for it. Regards, Jonas -- Jonas Eriksson Consultant at AS/EAB/FLJ/IL Combitech AB Älvsjö, Sweden _______________________________________________ netcf-devel mailing list netcf-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/netcf-devel