Ondrej Zajicek <santiago@crfreenet.org> writes:
On Tue, May 30, 2017 at 01:48:10PM +0200, Ondrej Zajicek wrote:
On Tue, May 30, 2017 at 01:37:56PM +0200, Toke Høiland-Jørgensen wrote:
Also channel_is_active() is called but channel may not even exist?
Ah, proto_configure_channel can leave the channel var entirely unset?
Yes, it could add/remove/reconfigure the channel, based on whether there is or is not the configuration and the old channel.
was assuming it was just leaving it in place but inactive. Can I just check for NULL, then?
Yes, that should be enough, as all channels goes up together with the protocol and channel cannot be deconfigured when up (protocol will be restarted in that case).
Well i checked that one more time and it is possible that channel is added after the protocol is up. So you should check that channel is non-NULL and in state CS_UP, which is something slightly different than what is checked by channel_is_active().
Right. In that case, is the overhead of always initialising both FIBs acceptable? If it is, I can just use the presence of the channel in all checks for whether an address family is active or not... -Toke