Debian package for cjdns with optimizations

[benhylau]

See: https://github.com/phillymesh/cjdns-optimizations#optimized-build

[Famicoman]

Side note: Something went a little haywire when I upped the kernel to 4.10 and upped jessie to stretch. The neon flag is accepted for building but the cryptofuzz test fails. I'm not sure if it is not properly supported, or if I have a botched installation somewhere. I'm curious to hear from others who upgrade in any fashion and try a build with neon.

[benhylau]

The current state is that cjdns gets included in a non-standard way. It gets included as a binary into the image. The main reason is that it pulls in Python, which adds ~100 MB to the tiny disk image, so @hamishcoleman has stripped out all that from the custom binary he built. This is a short-term solution however.

The long-term plan for this is to include this in the top right debian box. Host on a deb repo a minimal binary of cjdns, add that repo to the debian_repo so multistrap can pull it in. The deb repo should have binaries built for major architectures:

• armhf
• amd64

We should not publish device-specific binaries, just one binary for each major architecture. Board-specific _sub-_optimizations should be selected at runtime. For example, the armhf binary may contain :

sha256 (generic C code, no optimizations)
sha256_armhf_generic (contains some restricted set of assembly for generic optimizations on ARM)
sha256_armhf_neonfp (optimizations requiring neon floating point hardware)
sha256_armhf_vfp7 (optimizations requiring vfp7 floating point hardware)

All these should be packaged into a single armhf binary and which one to execute is a runtime decision.

[Famicoman]

Tell me more about how the board specific optimized binaries work. Are you running an apt server so we can import keys and add something to apt-sources.list? How are the specific board optimized binaries determined for use at runtime? These can all live in one binary?

[benhylau]

Are you running an apt server so we can import keys and add something to apt-sources.list

Yes, that is the plan.

These can all live in one binary?

Only two binaries: armhf (for all the SBCs) and amd64

How are the specific board optimized binaries determined for use at runtime?

An ARM board will get the armhf binary, and has to choose one of the following object files (all of which are included in that binary) depending on whether it has neon, vfp7, or neither:

sha256_armhf_generic
sha256_armhf_neonfp
sha256_armhf_vfp7

[benhylau]

RE: Debian pkg see:

• https://github.com/darkdrgn2k/ToMeshStuff/tree/master/deb
• @MakeItGreatAgain has an existing package that bundles python and nodejs for reference

This one can be a separate deb package that can bring cjdns tools without need for python and nodejs (mesh-orange already has perl):

• https://github.com/hamishcoleman/cjdns_tool

[benhylau]

Working on a reproducible environment to produce .deb packages for both cjdns and yggdrasil. Not sure yet if I will host the packages on a repo yet: https://github.com/benhylau/mesh-router-builder

I would also like to use the Vagrant machine to build mesh-orange images.