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
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
