11:37 a.m.
On Fri, Jul 31, 2009 at 06:00:22PM +0200 David Lutterkort wrote:
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 ?
Well, SuSE does not have any mechanisms for finding an interface
with a given mac address built into the ifup-system, as it relies
totally on udev. Having the MAC address in the XML is however not
meaningless, as it is possible to implement this searching in the
driver.
> 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 have only broken out the logic to make sure it is the same for
every driver (the logic implementation is not too complicated to
implement on a per-driver basis). normalize_if uses
platform-native MAC address lookup functions (from dutil_linux.c,
for example) to look up the correct interface using the priority
logic earlier described in this thread.
My thoughts have been going into a even more general
lookup-utility that should simplfy this even more. It's now
adapted for the SuSE-driver, so I should make sure it is portable
to the initscripts driver before showing the code.
> > 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.
Well, it sounds to me that this depends on what logic we want to
use when identifying drivers. As we can use the information to
write the correct ifcfg- files, the information is not wasted.
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)
Even if it is done with udev rules, we have to handle the case of
a mismatching MAC address when trying to apply an XML. I
understand that my perferred solution is clearly the hard way, by
going past the subsystem (the ifup-scripts) to do the lookup. It
is now up to me to prove that this can be done without much
impact to the code base of one single driver :)
Implementing and using this prio logic is what is needed to solve
this problem correctly:
1. Save all configs using netcf dumpxml
2. Reinstall (new kernel, eth dev renumbering)
3. Define all interfaces using netcf define
One can save the generated udev rules as well, but my opinion is
that you should not have to if you have your netcf XMLs :)
/Jonas
--
Jonas Eriksson
Consultant at AS/EAB/FLJ/IL
Combitech AB
Älvsjö, Sweden