[netcf-devel] mac-tag in XML

David Lutterkort lutter at redhat.com
Fri Jul 31 16:00:22 UTC 2009


On Thu, 2009-07-30 at 09:49 +0200, Jonas Eriksson wrote:
> As SuSE's ifcfg-files do not have the possibility of this (other
> than the ifcfg-eth-id-aa:bb:cc:dd:ee:ff in earlier verions), and
> only handles mac-mapping through udev the behavior of the driver
> is correct as implemented now, then.

For SuSE, the MAC address in the XML is completely meaningless then ?

> I'm also thinking of moving this lookup code to dutil.c, to make
> the prioritization more easily accessable. The prototype looks
> like this and will always return a malloced string (or NULL if
> name == NULL and no interface with matching mac was found):
> char *normalize_if(struct netcf *ncf, const char *name,
>     const char *mac);

Not sure I understand - how can this be done in a driver-independent
way ? I've been working on doing this for the redhat driver (given the
name of an interface, find the ifcfg-* file for it), but the logic is
completely RH specific.

> > I didn't add a <mac> to vlan interfaces, because they always get their
> > MAC address from the underlying device, and that device is known becuase
> > of the naming convention for vlan's. But if you see a need to specify it
> > explicitly, we can easily add that to the schema as an optional entry.
> 
> Yes, but we do have to find that underlying device somehow, and
> perferrably do this through the same logic as when finding bridge
> slaves or ordinary interfaces. My point is that you should be
> able to say "vlan 5 of the interface with mac X", much like "br0
> should enslave the interface with mac X".

With the way netcf writes out ifcfg- files, the MAC address is never
needed for an interface, and it sounds the same is the case for SuSe.

It's actually starting to be highly questionable to me that we ever
added the MAC to the XML (it's useful for reporting back, but not useful
in establishing the MAC - interface connection, which in newer distros
should be done with udev rules, anyway)

David




More information about the netcf-devel mailing list