[OE-core] RFC: Who wants/cares about SLiRP networking for QEMU?

[Jason Wessel]

On 05/08/2012 08:19 PM, Scott Garman wrote:
> This is an inquiry to see if there's much interest in adding an 
> alternate networking capability for our QEMU setups. Currently, we use 
> tun/tap devices, which need root privileges to be created. Hence, our 
> runqemu script requires sudo access.
>
> I'm curious to know who would like to see us use an alternate mechanism 
> (most likely SLiRP) to get around the need for sudo access. Is this much 
> of a problem for anyone, or would the team's resources be better spent 
> on other bugfixes?
>
> Secondly, does anyone have any war stories about using SLiRP for this 
> purpose? Is there a better way we should consider doing this?

We have QEMU + UserMode NFS + SLiRP for years in Wind River Linux products.   In that period I have sent upstream most of the patches dealing with problems.  There remain a few patches to the User Mode NFS service which are not currently in the Yocto project.  I also have a patch that is not in the QEMU mainline that deals with syn packets where QEMU violates the RFC that was never merged upstream for some reason.  I imagine that you will probably want all those patches if that is going to be your mode of operation.

You will also want to create a mechanism to easily add port redirections.  Typically we have always used what we call an simulator "instance" number so we know the ports are at generally fixed locations and for each instance number all the port redirections are incremented by 100.

Cheers,
Jason.