Hi Vasily,
thanks for this nuanced discussion. It helps me lot to understand your situation. For example, I didn't have the binary-blob problem on my radar at all.
I agree that would be worth L4Linux seen only as a sandbox for Linux binaries execution. Again, ideologically correct exclude drivers from L4Linux. But there are some problems. In addition to the noticed above there is another one. Is is a performance. Now we make some experiments with L4linux as gateway with two dedicated NIC drivers and L4Linux. And we see that the performance degradation is around 85% in contrast with Linux. That is too much, and if it turns that the moving NIC driver back to L4Linux ( ie if we give acces L4Linux network driver to HW) can decrease performance degradation (security architecture allows to do it), we will use this approach.
I suspect that the poor networking performance stems from the dde_ipxe networking driver, not L4Linux. I would definitely recommend to benchmark the dde_ipxe networking driver individually without L4Linux. E.g., by adding some code to the driver that transmits a predefined network packet and measure the throughput achieved.
Another test would be to connect two L4Linux instances via nic_bridge and perform the benchmark between both instances. If the communication over the virtual network performs well, we can rule out L4Linux and the 'Nic_session' interface from being the problem.
And oddly enough, the applications for the ARM easier develop from scratch and not use L4Linux for binaries execution. While software for network equipment, based on x86, increasingly require re-using. We have not looked NOVA and Vancouver yet. If we can not solve performance problems with L4Linux we will "taste" them.
Please let us know how you like the taste once you try it. ;-)
Norman