<div dir="ltr">Hi, <div><br></div><div>This doesn't default to slirp, it just allows it as an option.</div><div><br></div><div>In particular, on CROPS containers on Windows 10 and Mac OSX Â the hypervisor is *not* a linux kernel. This means that the only way we can run qemu in the container for testing/debugging is to run it in slirp mode .since there is no tun/tap device or driver.</div><div><br></div><div>So, given that we </div><div>1) are not defaulting to slirp and are merely enabling it</div><div>2) need slirp mode to be able to run in a CROPS container setting</div><div><br></div><div>I think this makes sense.</div><div><br></div><div>-Brian</div><div>an intel employee</div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 24, 2016 at 5:16 PM, Mark Hatle <span dir="ltr"><<a href="mailto:mark.hatle@windriver.com" target="_blank">mark.hatle@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/24/16 6:46 PM, Todor Minchev wrote:<br>
> On Mon, 2016-10-24 at 18:15 -0500, Mark Hatle wrote:<br>
>> On 10/24/16 5:19 PM, Todor Minchev wrote:<br>
>>> Using 'slirp' as a command line option to runqemu will start QEMU<br>
>>> with user mode networking instead of creating tun/tap devices.<br>
>>> SLIRP does not require root access. By default port 2222 on the<br>
>>> host will be mapped to port 22 in the guest. The default port<br>
>>> mapping can be overwritten with the QB_SLIRP_OPT variable e.g.<br>
>>><br>
>>> QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"<br>
>><br>
>> In the past patches like this have been rejected for performance and other<br>
>> reasons.<br>
><br>
> Performance is not ideal with SLIRP, but should be sufficient for basic<br>
> ssh access to the guest. Could you please elaborate on the other reasons<br>
> why having this is a bad idea?<br>
<br>
</span>You'd have to go back in the archives.  Performance was the main reason I<br>
remember being discussed at the time.<br>
<br>
I don't remember the others, and as I said, I'm not a fan of requiring root, but<br>
the community decided sudo approach was better as long as there was a way to<br>
avoid it.<br>
<br>
Changing the default will likely require email to the oe-core list and/or<br>
oe-architecture list...<br>
<span class=""><br>
>> While I don't particularly like requiring sudo access for runqemu,<br>
>> adding the 'slirp' option will allow someone w/o root/sudo to be able to run it.<br>
><br>
> The goal was to be able to run a QEMU image and provide basic networking<br>
> without requiring root access. Is there any reason why running runqemu<br>
> w/o root/sudo access should be discouraged?<br>
<br>
</span>As long as you can pass in slirp (and it's not the default) then I believe your<br>
requirement and the community direction is preserved.<br>
<span class=""><br>
>> Otherwise, if there is something you can do to make slirp work better (when<br>
>> enabled), that is more likely to be accepted.<br>
><br>
> Similar SLIRP support has been already accepted for qemuarm64 with<br>
> commit 9b0a94cb<br>
<br>
</span>Support for slirp is good, it's defaulting to slirp that has been rejected in<br>
the past by the community.<br>
<div class="HOEnZb"><div class="h5"><br>
> --Todor<br>
><br>
> Intel Open Source Technology Center<br>
><br>
>> --Mark<br>
>><br>
>>> Signed-off-by: Todor Minchev <<a href="mailto:todor.minchev@linux.intel.com">todor.minchev@linux.intel.com</a><wbr>><br>
>>> ---<br>
>>>  meta/conf/machine/include/<wbr>qemuboot-x86.inc | 1 +<br>
>>>  scripts/runqemu  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  | 3 ++-<br>
>>>  2 files changed, 3 insertions(+), 1 deletion(-)<br>
>>><br>
>>> diff --git a/meta/conf/machine/include/<wbr>qemuboot-x86.inc b/meta/conf/machine/include/<wbr>qemuboot-x86.inc<br>
>>> index 06ac983..0870294 100644<br>
>>> --- a/meta/conf/machine/include/<wbr>qemuboot-x86.inc<br>
>>> +++ b/meta/conf/machine/include/<wbr>qemuboot-x86.inc<br>
>>> @@ -13,3 +13,4 @@ QB_AUDIO_OPT = "-soundhw ac97,es1370"<br>
>>>  QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1"<br>
>>>  # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy<br>
>>>  QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci"<br>
>>> +QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"<br>
>>> diff --git a/scripts/runqemu b/scripts/runqemu<br>
>>> index dbe17ab..6952f32 100755<br>
>>> --- a/scripts/runqemu<br>
>>> +++ b/scripts/runqemu<br>
>>> @@ -542,7 +542,8 @@ class BaseConfig(object):<br>
>>>  Â  Â  def check_and_set(self):<br>
>>>  Â  Â  Â  Â  """Check configs sanity and set when needed"""<br>
>>>  Â  Â  Â  Â  self.validate_paths()<br>
>>> -  Â  Â  Â  check_tun()<br>
>>> +  Â  Â  Â  if not self.slirp_enabled:<br>
>>> +  Â  Â  Â  Â  Â  check_tun()<br>
>>>  Â  Â  Â  Â  # Check audio<br>
>>>  Â  Â  Â  Â  if self.audio_enabled:<br>
>>>  Â  Â  Â  Â  Â  Â  if not self.get('QB_AUDIO_DRV'):<br>
>>><br>
>><br>
><br>
><br>
<br>
--<br>
______________________________<wbr>_________________<br>
yocto mailing list<br>
<a href="mailto:yocto@yoctoproject.org">yocto@yoctoproject.org</a><br>
<a href="https://lists.yoctoproject.org/listinfo/yocto" rel="noreferrer" target="_blank">https://lists.yoctoproject.<wbr>org/listinfo/yocto</a><br>
</div></div></blockquote></div><br></div>