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