Ondrej Zajicek <santi...@crfreenet.org> writes: > 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.
Except that the way I implemented things, I just select select the right fib based on address family; so I'll have to litter checks through all of that code just to save a few dozens of bytes of memory... Is that really worth it? -Toke
