RFC: Who wants/cares about SLiRP networking for QEMU?
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?
Thanks,
Scott
Signature · 3 lines
Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center
Quoted 5 lines · Scott Garman
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.
Quoted 7 lines
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.
Quoted 23 lines · Jason Wessel
Quoted 5 lines · Scott Garman
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.
Quoted 7 lines
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.
Quoted 5 lines
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
Signature · 3 lines
Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center