On Mon, Feb 08, 2010 at 01:56:03AM -0200, Christiano F. Haesbaert wrote: > On Sun, Feb 07, 2010 at 04:29:39PM -0800, Philip Guenther wrote: > > On Sat, Feb 6, 2010 at 3:46 PM, Christiano F. Haesbaert > > <[email protected]> wrote: > > > Any feedback on this ? > > > > Yep: just committed along with the same thing in dvmrpd. This was > > originally a bug in ospfd, from which both ripd and dvmrpd were > > cloned, but it was fixed is the original back in 2006. Maybe we've > > got enough of these that pulling out the common bits into a library > > (or shared .c file) can actually be done without exploding into > > generalities... > > > > Since you've touched the subject, isn't the time for having a kroute > and iface library ? Looks like all routing daemons use them with very > little modification. > > I ended up using them in my mdnsd, made the copy from ripd, I know > they act more like frameworks, but a iface / kroute library could give > us something like a full general "netlink" library. >
Did you actually diff the various versions? bgpd: IPv4 and IPv6 capable, needs a nexthop tree, will support multiple tables ospfd: IPv4, multipath aware, no need for nexthop tree ospf6d: IPv6 version of ospfd ripd: IPv4 but no multipath (which is probably a bug) dvrmpd: multicast mayhem has nothing in commen with the other There is no common interface. Sure I try to keep them similar but one generic library would bloat the code. The routing socket is already a full and general API so why adding another special layer on top of it? The routing socket is not that hard, the only thing I miss are the helper functions to extract the sockaddrs which are copied all over the tree. -- :wq Claudio
