<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 19, 2018 at 3:49 PM, Gerd Hoffmann <span dir="ltr"><<a href="mailto:kraxel@redhat.com" target="_blank">kraxel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  Hi,<br>
<span class=""><br>
> > Can you summarize the reasons to discard the approach?<br>
> ><br>
> <br>
> I will try.<br>
> <br>
> The POC of nbd-based cd sharing was on the table. It needed some<br>
> unclear rework to avoid breaking ABI with mainstream spice-server.<br>
<br>
</span>--verbose please.<br></blockquote><div><br></div><div>POC = proof of concept</div><div>ABI = application binary interface</div><div>spice-server changes were backward-incompatible and were not accepted</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> The solution requires updates in qemu and spice on server side and<br>
> spice and spice-gtk on client side.<br>
<br>
</span>Sure.<br>
<span class=""><br>
> Then it is functional with command-line qemu.<br>
> In order to make it available to regular user need to update at least also<br>
> libvirt and virt-manager<br>
> (to add new nbd chanels), remote viewer (to select what to share).<br>
<br>
</span>Yes, but for compensation you can drop code emulating usb-storage and<br>
scsi spice-gtk.<br></blockquote><div><br></div><div>usb-storage is just a header processing and holder of units <br></div><div>scsi source is 2K lines, similar to nbd server</div><div>nbd requires also code for nbd channel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> The user experience is also changed - any user (whether it plans to<br>
> share cd in this session or not) have on guest machine several<br>
> additional unloaded drives (to be loaded when the sharing triggered on<br>
> client side).<br>
<br>
</span>Yes.  But why is this a problem?  If the user can share one (or maybe<br>
two for both installer and driver) iso images, having that many cdrom<br>
drives in the guest should not cause much confusion, no?<br>
<span class=""><br></span></blockquote><div><br></div><div>And if the user does not want to share anything? Why he/she must have these</div><div>drives? In case of usb redirection the device does not exist if it is not used.</div><div>With usb redirection the number of emulated drives on single channel</div><div>is potentially unlimited (using multi-unit device)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Current solution is client only (even spice-gtk only), works on any setup<br>
> even with old server side.<br>
<br>
</span>So you trade short-term simplification (only spice client update<br>
needed) over long-term maintainance requirements (all the additional<br>
usb/scsi emulation code in spice-gtk).  I don't think this is a good<br>
idea.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
cheers,<br>
  Gerd<br>
<br>
</blockquote></div><br></div><div class="gmail_extra"><br></div></div>