Ben Greear wrote: >> >> The RTA_TABLE stuff looks interesting and useful, do you plan to >> forward port this to the HEAD revision? > Yes, I plan to port everything to HEAD, and drop whatever is fixed by > Pavlin's fixes. When I get something > working again, I'll post it.
Excellent, look forward to it. >> The RIB shouldn't really be setting the admin distance for >> static_routes at all. > My hack works for me (and is small and easy to keep merged)..but I'll > gladly drop it if someone adds the ability to do it right. The infrastructure's all already there; the protocol(s) just need to be taught to send a "set_protocol_admin_distance" XRL to the RIB before they try to register their OriginTable(s). It should only be done once and specify the RIBs which the process plans to add routes to. OLSR only ever originates unicast IPv4 routes at the moment; see XrlIO::register_rib(). I had some snafus during development because I'd left in a call to register a multicast table, but didn't include it in set_protocol_admin_distance, which used to cause an error in the RIB; this has since been demoted to a warning. It isn't possible to do this for *all* of the protocols, particularly the "connected" table which has special meaning to the RIB. Also, the RIB does not yet handle changing admin distance for a running process, because this involves blowing away of a lot of RIB and FEA state; the code path to do it hasn't been written yet. It has to be done though as the admin distance gets embedded in every OriginTable which a routing protocol instantiates. >> >> P.S. __PRETTY_FUNCTION__ is gcc specific. > > It would be easy enough to #define it to something similar for non-gcc > compilers...no need to remove useful functionality > for the majority of the target platforms just because some don't > support a feature... No need to cause breakage when gcc is not being used for an equally good but unspecified reason :-) I've been looking at doing some logging code related to the very specific needs of routing processes -- __PRETTY_FUNCTION__ is useful, as it produces a fully qualified, undecorated name, including the class name, which you can then strsep() on "::" as a delimiter; but because it's non-standard, it breaks with anything which isn't gcc. If you look around there's a proposal from an ex-Apple guy to add __class__ to the C99 and C++0x specs, it might be good to give him some political support somehow. cheers BMS _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
