Re: [Rpcemu] Config-free networking work-in-progress (was: Patch for 0.9.1 - Mac keyboard support)

QEMU uses a library called SLIRP, which contains its own ethernet stack,
including servers to do DHCP, DNS, etc.  When a QEMU VM wants to use the network,
the default mode is to push packets into SLIRP which will NAT them and emit
them from the QEMU app as if they were native connections.  This enables
no-setup networking for QEMU VMs, and it's the default way that QEMU uses.
In principle, doing the same for RPCEmu would allow no-setup networking
across all the platforms it supports.

I have previously done some work integrating Slirp with RPCEmu, and got further than you, because I can send and receive network packets :)

There's a lot to think about before integrating and releasing the code as is, but the ultimate aim is to get user-friendly networking with the absolute minimum number of configuration steps.

One of the challenges of incorporating Slirp was that there are so many derivatives of the original code base, and they tend to differ in their suitability. Here are some of the things I've considered when selecting which Slirp code to integrate:

* Not all Slirp derivatives are easy to extract and integrate with RPCEmu. The copies in QEMU and VirtualBox are fully-featured, but are very difficult to integrate.

* Not all Slirp code is portable to 64-bit platforms or Windows, as the original code was only for Unix.

* Only some Slirp code has good support for DHCP.

* Only some Slirp codebases support port-forwarding, which I consider a highly desirable feature.

* Few Slirp codebases support DNS proxying, and this I consider an essential feature (see below).

The DNS proxying I consider an essential feature, because without it the user would not only have to manually configure DNS (which would seem odd given that the rest of the config would be automatic), but they would have to change their RISC OS config every time they moved to another network, which laptop users would be very likely to do.

I got to the point of having Slirp integrated and working on Linux, though without support for the DNS proxying feature. However, testing showed up deficiencies and bugs in the other parts of the network code including the EtherRPCEm driver, and that is where most of the recent effort has been expended.

I expect that there's still a lot to do on networking, but the long-term plan is definitely to go with Slirp (or if not Slirp, something equivalent). This would become the recommended networking option, and the most portable option.

Matthew