Changes in the network code

Bad news, with a silver lining: both libvirt and lxc on Linux are currently unuseable disasters. I have never seen systems software designed that badly - both packages consist of huge, unweildy libraries which, instead of talking to the underlying OS as system libraries should, instead wrap system() calls to command-line utilities! This isn't portable, doesn't work at all for embedded systems which might not have a POSIX shell or execution environment, doesn't allow for static linking, and too many other problems to mention them all here. I spoke with the liblxc development folks and they showed me some of the C headers they are working on for a "real" (i.e. properly designed) LXC library, but it isn't even close to done being designed, let alone implemented.

This state of affairs is requiring me to fall back to using libc to access TCP sockets and giving up on working with a virtual networking setup. The only other thing I could do would be to haul in to Controlix's codebase a TCP/IP library like TinyIP and wire that directly into a TUN/TAP interface. I don't really want to do that, though, at least not right now - it would require me to to wrap a native multithreaded and callback-laden native codebase into Controlix, and IMHO that is too much wierd stuff on the native side for a codebase which is supposed to be evolving into an operating system which can run on bare-metal hardware with minimal non-VHDL glue required. I will eventually code up a real TCP stack in VHDL, which will put an end to this issue.

The bright side of all of this is that I have been able to map a simple numeric address onto TCP port numbers instead of network addresses, which is much simpler to handle in general. It is going to make my message-passing protocol a bit wierd (I wanted to use Mbus over TCP, not going to happen anytime soon), but I can in principle handle that for now. I can even simulate TCP broadcast to address 255 (needed for the DHCP-style network server configuration I am using for server controls) by blasting the same message at every port in the address range using a simple for loop |->. I'll only be able to handle 256 - 3 (broadcast, gateway and whatever .127 is reserved for) controls in a test system until this is resolved somehow, but that probably won't be a problem for a little while for anything but RAM addressing, which I will have to serialize access to with a protocol or something.

Even though it has been an exhausting, painful, frustrating and ultimately bitterly-defeating week dealing with the virtualization-support crapo that comes with Linux userspace these days, I am at least done with it for now and can move on with Controlix's development. I have all of the current test components (boot, init, console_server, shell, and hello_world) properly initializing their networking subcontrols now, and I am moving on the getting the shell code to properly construct messages for the console_server control so I can broadcast a message to request the server address and get the server address back in a message properly as well as generate and handle messages for printing to and reading characters from the console. It is nice to be working on Controlix again, instead of doing system adminsistration.