Or Gerlitz <[EMAIL PROTECTED]> wrote:
>+ /* XXX set the bond dev type and addr len such that the net core code
>+ * (eg arp_mc_map() in net/ipv4/arp.c) would correctly process multicast
>+ * groups set ***before*** the first enslaveness
>+ */
>+ bond_dev->type = bonding_dev_type;
>+ bond_dev->addr_len = bonding_dev_addrlen;
I've been thinking about this a little bit more. The system is
understandably not set up to deal with this situation, since normal
devices won't ever change their hardware type.
You almost want to have some kind of call to induce a reload
from scratch of the multicast filter settings (along with whatever else
might be necessary to alter the hardware type on the fly), to be called
by bonding at the time the first slave is added (since slave adds happen
in user context, and can therefore hold rtnl as required by most of the
multicast address handling code). That seems less hassle than having to
specify the hardware type and address length at module load time.
A side effect of this is that bonds would have to be restricted
to consisting only of slaves of one hardware type, since slave changes
(and thus hardware type changes) aren't necessarily restricted to user
context.
Other random thoughts on how to resolve this include modifying
bonding to accept slaves when the master is down (which would also
require changes to the initscripts that normally configure bonding), so
that the initial setting of the, e.g., 224.0.0.1 multicast hardware
address happens to the already-changed hardware type.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
