[Ns-developers] Learning Bridge, NetDevice API changes

[Gustavo Carneiro]

2008/7/4 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>:

> hi gustavo,
>
> Very early comments below: I will review the code more carefully in a
> couple of days.
>
> 1) BridgeNetDevice::GetChannel should be implemented correctly, that is,
> it should return a BridgeChannel which is created on the fly and
> references the channels of the underlying devices: it is important to
> implement as much as you can of the NetDevice API if it makes sense and,
> in this case, it makes perfect sense to make the bridge report as
> neighbors the neighbors of its underlying devices.


What is the use case for that?  global routing manager?  That kinda makes
sense, actually.


> 2) I really would like to avoid the extra cruft you have added for 'api
> compatibility'. This means that:
>  - we could re-use the rx callback in promisc mode


But it needs to change not only API but also semantics.  I think if the
semantic change is restricted to NetDevice->Node, not so bad, but from Node
to protocol handlers it is really bad.


>
>  - no need for the new Node::Register/Unregister methods you have added


OK, but as I say above, protocol handlers should at least be able to specify
whether they want promiscuous packets or not, via a flag parameter.


>
>  - need to add enable/disable methods for promisc mode


Same comment as above.  Don't you think it's evil to have a promisc mode
enable/disable?  I mean, suppose we have a simple protocol handler.  Next,
some unrelated code activates promiscuous mode.  The first protocol handler
starts receiving packets it is not prepared to receive, and did not expect.


>
>
> 3) What is SupportsPromiscuousReceiveCallback used for ? When do you
> envision a device which could refuse to support this mode ?


That is for compatibility only.


-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert