On Tue, May 30, 2017 at 02:04:00PM +0200, Toke Høiland-Jørgensen wrote: > Ondrej Zajicek <santi...@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...
I see no reason not to do conditional initialization of FIBs in babel_start(). If a channel appears later, it will stay in CS_DOWN until protocol restarts (and FIBs are reinitialized), so you could still just use the presence and CS_UP state of channel and do not need to check for FIB. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
