From: Marc G. <gr...@at...> - 2009-01-29 15:39:44
|
Hi Gordan, On Thursday 29 January 2009 12:21:52 Gordan Bobic wrote: > Hi, > > Replying here because I thought it was too discussiony for a bugzilla > comment. I see ;-) > > # A new attribute driver per nic per clusternode was introduced. > # <eth name=".." mac=".." driver=".."/> > > I can see that this is useful for heterogenous clusters, but if "driver" > isn't specified, the NIC driver "probing" shouldn't really occur at all. It > should be done according to the content of modprobe.conf. I think this > should be deemed authoritative unless specifically overriden by the driver > parameter in the NIC spec. Yes an no. See below. > > Also, what happens if we have an alternating NIC driver setup, e.g. > > eth0 e1000 > eth1 e100 > eth2 e1000 > > Will this work correctly, or will loading the e1000 driver wrongly make the > two e1000 NICs eth0 and eth1? Yes I think it will. See below. > > If udev configuration is dynamically generated from cluster.conf by MAC > address using a line like: > KERNEL=="eth*", SYSFS{address}=="00:11:22:33:44:55", NAME="eth0" > that should probably suffice. > Unfortunately, AFAIK this is not redundant with modprobe.conf stuff (need > the driver loaded before we can read the MAC). Still, I feel there is a > strong argument for making modprobe.conf the default. > > Or, as a potentially easier-to-implement alternative, maybe it would be > better to make the driver parameter mandatory (assuming it isn't at the > moment) and abort mkinitrd if it isn't provided. What we do is start udevd then implicitly let it autoload the mods. Save the MACs (note the first udevtrigger is only used to detect the MAC). Then the modules are unloaded again. And now they are (newly) loaded in the following order. 1. If a driver is defined in cluster.conf (eth@driver) it has precedence 2. Load the eth* which are defined in modprobe.conf 3. Trigger udev This should still be stable. Note: The first triggering of udev is just to cause the modules to be loaded once to save all MAC addresses. Then they are unloaded again. But in order to detect the nics I can also change the process like as follows: 1. load drivers as specified in modprobe.conf 2. Save the drivers 3. Trigger udev 4. Save macs 5. Unload all newly loaded drivers But I think this wouldn't be too universal. As It does not really work stable for currupt modprobe.confs. The other way would do the same and additionally would also work with corrupt modprobe.confs and @driver in the cluster.conf. I still think this is a general way which is quite stable and most universal. -- Gruss / Regards, Marc Grimme http://www.atix.de/ http://www.open-sharedroot.org/ |