<div dir="ltr">Christophe,<div><br></div><div>Our primary goal, if you remember, was to deliver cd-sharing feature.</div><div>For that it was needed to isolate usb redirection modules from libusb and usbredir to create some abstraction layer for USB devices whether they are local or emulated in software.</div><div>SpiceUsbDevice is type of object that Usb Device Manager uses internally, opaque for other modules and external API, with its own life cycle and with system dependent structure. It is referenced by external components (as widget or external application).<br></div><div>Introduced by us SpiceUsbBackendDevice is used by abstraction layer internally, with its own life cycle and opaque for all other modules with system-independent structure.<br></div><div><div>Current commit makes minimal changes in existing modules and serves the initial goal.</div><br class="gmail-Apple-interchange-newline"></div><div>Your suggestion breaks the initial goal and moves us to additional refactoring of already prepared 'engineering stable' code and additional complicated (IMO) reintegration with USB device manager.<br></div><div>This also breaks the original idea of isolation - such a way all the internals of 'backend device' will be visible to usb device manager, including libusb.<br></div><div>I do not see what is advantage of doing this and especially of doing this right now.</div><div><br></div><div>From my point of view, the order should be following:</div><div>1. Finalize step 1 patches (isolation, opaque usb backend)</div><div>2. Add cd-sharing  feature above it</div><div>3. Finalize UI solution that serves cd-sharing</div><div>4. Reduce differences between Linux and Windows in Usb device manager (persistent backend device object)</div><div>5. Reevalute the plans of unifying internal data structures (if this makes sense).</div><div><br></div><div>Thanks,</div><div>Yuri</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 27, 2018 at 3:00 PM Christophe Fergeau <<a href="mailto:cfergeau@redhat.com">cfergeau@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey,<br>
<br>
One additional high-level comment, after these patches, we have<br>
in the public API an opaque SpiceUsbDevice, which is<br>
// this is the structure behind SpiceUsbDevice<br>
typedef struct _SpiceUsbDeviceInfo {<br>
    guint8  busnum;<br>
    guint8  devaddr;<br>
    guint16 vid;<br>
    guint16 pid;<br>
    gboolean isochronous;<br>
#ifdef G_OS_WIN32<br>
    guint8  state;<br>
#else<br>
    SpiceUsbBackendDevice *bdev;<br>
#endif<br>
    gint    ref;<br>
} SpiceUsbDeviceInfo;<br>
<br>
SpiceUsbBackendDevice is<br>
struct _SpiceUsbBackendDevice<br>
{<br>
    union<br>
    {<br>
        void *libusb_device;<br>
        void *msc;<br>
    } d;<br>
    uint32_t isLibUsb   : 1;<br>
    uint32_t configured : 1;                                                                             <br>
    int refCount;<br>
    void *mutex;<br>
    SpiceUsbBackendChannel *attached_to;<br>
    UsbDeviceInformation device_info;<br>
};<br>
And UsbDeviceInformation is<br>
typedef struct UsbDeviceInformation<br>
{<br>
    uint16_t bus;<br>
    uint16_t address;<br>
    uint16_t vid;<br>
    uint16_t pid;<br>
    uint8_t class;<br>
    uint8_t subclass;<br>
    uint8_t protocol;<br>
    uint8_t isochronous;<br>
    uint8_t max_luns;<br>
} UsbDeviceInformation;<br>
<br>
This is really redundant, from experimenting a bit, it seems the<br>
SpiceUsbBackendDevice + UsbDeviceInformation you add in this patch could<br>
instead be SpiceUsbDevice. In short, I'd move SpiceUsbDeviceInfo<br>
definition from usb-device-manager.c to a new usb-device.c (aka<br>
usb-device-backend.c), and then add the new API introduced in your patch<br>
on top of that, using SpiceUsbDevice everywhere rather than adding<br>
SpiceUsbBackend.<br>
<br>
Christophe<br>
</blockquote></div>