[RFC] fork rfc5444 reader/writer from oonf_api, introduce lib/

Hi, the olsr project provides a framework to aid implementation of routing protocols, the oonf_api. olsrd2 is heavily based on this, it provides OS abstraction and common functions needed when implementing a routing daemon. Most of this is not needed in RIOT, but the interesting part is an implementation of a rfc5444 (Packet/Message Format for MANET protocols) reader/writer. [1] So far I've been trying to track the upstream code and just add a few patches [2] on top to build it with RIOT. It however requires some not-so-nice compatibility defines [3] and carries some craft that is not needed/available on RIOT. Besides the rfc5444 implementation, I'd also like to add the common folder, which contains a double-linked-list, an AVL-tree and netaddr implementation, the latter one could be greatly reduced as RIOT only supports IPv6/already provides some of the functions there.

Both folders are relatively small and have not received many changes lately and since they are already doing everything they are supposed to do, it's unlikely much will change in the future.

I propose adding common and rfc5444 to a new RIOT/lib/ folder where all non-essential libraries could live, to avoid cluttering /sys Alternatively, rfc5444 could reside in /sys/net and common would go to /sys, but as it's only used by rfc5444 any my olsr implementation, it wouldn't be all that common… Thoughts/Comments?

Benjamin

[1] http://olsr.org/git/?p=oonf_api.git;a=tree;f=src-api/rfc5444 [2] https://github.com/benpicco/oonf_api/commits/master [3] https://github.com/benpicco/riot-libs/blob/master/compat_misc/compat_misc.h

Hi Benjamin!

I propose adding common and rfc5444 to a new RIOT/lib/ folder where all non-essential libraries could live, to avoid cluttering /sys Alternatively, rfc5444 could reside in /sys/net and common would go to /sys, but as it's only used by rfc5444 any my olsr implementation, it wouldn't be all that common… Thoughts/Comments?

How about the solution that Martine proposed? Do you think that this looks like a practible way for rfc5444 and common?

Cheers, Oleg