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

[Scott Garman]

On 05/08/2012 06:28 PM, Jason Wessel wrote:
> 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.

Thanks Jason, this is exactly the kind of info I was hoping to learn 
about. It's possible/likely that I may not end up implementing this 
myself, but if the feature gets reassigned, I will make sure the 
implementor gets connected to you for those patches.

Thanks,

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center