[Ns-developers] NetDevice::SetAddress

[Mathieu Lacage]

On Thu, 2009-06-25 at 16:11 +0000, Tom Henderson wrote:

> >I can't comment on how this thing relates to the tap bridge (I did not
> >look carefully at bug 569) but, I wanted to point out a couple of things
> >about this change which make it look a bit fishy without more
> >information. Hopefully, someone can chime in and comment on my concerns.
> 
> I am not sure of where to point you to past list discussions on this
> but in the tracker recently for bug 569, I had suggested
> NetDevice::SetAddress() while this current patch was cooking.

I looked carefully at this specific change: my gut feeling is that it's
horribly wrong because this change feels way too much like the dreaded
NetDevice::SetChannel method I spent so much time killing. Sadly, I
can't think of any reasonable alternative right now: my intuition is
that changing the mac address of a device once it's constructed is wrong
and that we should instead focus on initializing it to the right value
in the first place from where we know the type of the address _and_ the
underlying device (we could get a Mac48AddressFactory from
TapBridgeHelper and feed it to another XXXHelper). Anyway, it's clearly
not something I can invest a lot of time thinking about now, a couple of
days before the release so, I am not going to push for a change there
right now.

A more important comment I have, though, is that it's probably not a
good idea to rely exclusively on a comment in a bug report to signal an
API change to other developers. With hindsight, I believe that you
mentioned that change to me on the phone but it probably did not even
cross my mind that to fix a bug in the TapBridge, you had to add API to
the NetDevice base class. So, I am at fault for not spotting this
potential change before but I think that, as a general rule, we should
be more careful in discussing API changes for src/node/* on
ns-developers. I know that it's more painful than private communications
and I can't claim I am a reference when it gets to this but I think that
we need to keep working on this.

Mathieu