netdev
[Top] [All Lists]

Re: [Bonding-devel] Re: [Bugme-new] [Bug 4189] New: IPv6 link local addr

To: Jay Vosburgh <fubar@xxxxxxxxxx>
Subject: Re: [Bonding-devel] Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Thu, 10 Feb 2005 19:44:54 -0800
Cc: yoshfuji@xxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, ikebe.takashi@xxxxxxxxxxxxx, akpm@xxxxxxxx, ctindel@xxxxxxxxxxxxxxxxxxxxx, bonding-devel@xxxxxxxxxxxxxxxxxxxxx
In-reply-to: <200502110240.j1B2eTj3001689@xxxxxxxxxxxxxxxxxxxxxx>
References: <20050210122745.16ca7cb3.davem@xxxxxxxxxxxxx> <200502110240.j1B2eTj3001689@xxxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Thu, 10 Feb 2005 18:40:29 -0800
Jay Vosburgh <fubar@xxxxxxxxxx> wrote:

>       Except that most of the bonding internal MAC changes won't
> generate any events (presuming you mean a NETDEV_CHANGEADDR).  The
> bonding driver calls the slave's dev->set_mac_address directly; the
> NETDEV_CHANGEADDR is generated by dev_ifsioc() (which isn't exported).
> Now that I'm looking for it, there are some other cases of bonding
> calling other dev->functions directly, e.g., change_mtu, that have
> wrappers that generate events; I need to fix that.
> 
>       Would you have a problem with putting the SIOCSIFHWADDR code
> from dev_ifsioc() into a separate exported function, similarly to how
> dev_set_mtu() is done?  I can probably whip that up along with the
> appropriate bonding changes this evening.

That would be a great idea, as I read your first paragraph I was
going to suggest exactly this.

<Prev in Thread] Current Thread [Next in Thread>