On Tue, May 26, 2015 at 02:58:54PM +0300, Timo Teras wrote: > On Tue, 26 May 2015 12:44:06 +0100 (BST) > Paul Jakma <p...@jakma.org> wrote: > > > On Tue, 26 May 2015, Paul Jakma wrote: > > > > > Anything sensible would probably do. This is for the link-layer > > > header type? > > > > libpcap might have useful headers on this, maybe. > > It has LINKTYPE_* and DLT_*. Both are bad choices, as same #define can > have different value on different platforms (at least for DLT_*). And > they contain more of the "the next header is of type XXX" than "this > device type X". In fact, on Linux it'll just usually say DLT_LINUX_SLL > "This is linux cooked capture header next", which will contain the > ARPHRD_* info. They have defines for pretty much all possiblities, as > they don't want to lose info received from upstream... > > But yeah, it really looks like there's no simple choice for this.
The simple choice is using it as-is :) The whole discussion is very academic to begin with. Some routing daemons could probably be constructed in an OS-agnostic way, but zebra doesn't provide a full abstraction - compare isisd containing multiple backends for raw packet TX/RX. As long as nhrpd uses netlink, it's Linux-reliant anyway and I don't see a problem with communicating hw_type. What we could do, though, is add an "__attribute__((deprecated))" to lib/if.h on struct if -> hw_type, to make sure that the daemons that are reasonably platform-independent don't start using the value (thus losing platform independence). That could be governed by a #define QUAGGA_NON_PLATFORM_AGNOSTIC (which would be set by lib/, zebra/, nhrpd/ and isisd/), which if set removes the deprecation attribute. (Should add that attribute to all platform-dependent fields.) > Re: zapi. If fixing this, we should really fix the way routes are > adverticed too. Nexthops are encoded differently depending if it's > zebra receiving or announcing it... They are not really AFI > independent... And there's no simple way to extend the protocol without > breaking ABI. To be honest, the whole protocol would need an update if > we wanted to make it usable for out-of-tree users (not to speak about > cross-platform) users. Yeah, OSR looked into this about 2 years ago, we did a prototype using Google's protobuf-c, but other stuff bumped it down the list and it never got past the prototype stage. (And while it worked, protobuf wasn't that good a choice.) However, I see no logic in tying nhrpd to this problem, so I'll just pick up the hw_type patch as-is if no one objects. -David _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
