> In the impromptu meeting on Thursday, I believe that James Woodyatt said > that his nodes have 64K of ram and that code executes-in-place out of > ROM. He didn't say how much of that 64K is currently used for data for > other parts of the system.
A box with that little RAM should definitely be using filtering to avoid growing its routing table. Whether that is better done using stock babeld with just two filtering rules or an ad-hoc daemon depends on how much ROM/flash you can afford. The point I'm making is that Babel has no link state database, so filtering is all that's needed to ensure that your memory usage doesn't grow -- there's no need for specific support for stub routers. (That is of course also the source of one of Babel's weaknesses -- you cannot easily obtain the full topology of your network, which complicates debugging --, but I think there's a saying somewhere about eating your cake.) > You have said that the Babel implementations have a sole requirement for > libc, but I don't know if they also require Linux? They need the sockets library (nothing fancy, just plain RFC 3493) plus a reasonably simple interface to the kernel routing tables, currently implemented for Linux netlink and BSD Unix. The only non-portable assumption I am aware of is that for link-local addresses sin6_scope_id is an interface index. > Are the current Babel implementations designed to execute-in-place out of ROM? We're speaking of plain C code with no dirty tricks, so there should be no issues. A small amount of hacking would be needed if they don't have malloc. I'll try to get in touch with James Woodyatt to ask him for more details. -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
