Thanks Benjamin for the feedback. Appreciate.
With regards to upstreaming, I had given it a good long thought, not only for RIOT but also for Contiki/Zephyr/OpenThread etc. The forks as you mentioned must be avoided.
I am working on something called “Plug-n-play mode” where you provide RIOT-binary compiled in the native mode “without Whitefield driver/netdev in RIOT”.
During node init/load, Whitefield overrides the tap interface (or UDP-socket in case of OpenThread) or even change netdev interface using a combination of LD_PRELOAD and -fPIC/-pie compilation mode (details ). The packets are intercepted, routed to backend NS3. For OAM, RIOT node shell access will be provided directly by overriding the pseudo-terminal. There is some ABI dependency, especially where feedback from phy/mac (for e.g., L2-ACK failure or setting RSSI/LQI) is provided back to RIOT. In this case, RIOT/Contiki internal API is called (bin is compiled with -fPIC,-pie options) and this means ABI dep. But the good news is that these interfaces seldom change and Whitefield can do a pre-elf-check on the binaries before forking the bins.
Looking for any critical feedback if something basic is amiss here.
All in all, the point is, if this works then upstreaming code won’t be necessary.
Btw, I have been given an opportunity to present this work in the upcoming RIOT summit. Stay tuned.
 https://github.com/nyrahul/preload … Technical details on how preloading/interceptions/runtime-API-injection will work.