On Mon, Apr 06, 2015 at 03:09:51PM +0900, fx IWATA NOBUO wrote: > Dear Greg, > > Thank you for your comment. > > 1) About wrapping > > > You do this on all of your patches, please wrap your changelog lines at > > 72 columns so they show up correctly in the log. > > Very sorry. Could I send them as V2? Please do. > Before that, I posted graphical version to my blog instead of the ASCII diagram. > http://linux-usbip-additions.blogspot.jp/2015/04/figs-user-space-urbs-transmission.html > > 2) Why not use usbfs > > > This is really interesting, but how does this tie into usbfs where you can > > send and receive USB urbs today from userspace to USB devices? Why do you > > need another user/kernel interface here? > > There are 2 reasons. > > 2-1) Application(vhci_hcd) side is also needed > > In my understanding, usbfs provides functions to control USB devices. So device(usbip_host) side can be done by usbfs but application(vhci_hcd) side cannot. My patch covers both device(usbip_host) and application(vhci_hcd) side. And it is quite the same in both side and works symmetrically. Please wrap your email lines too :) Why do you need host side as well? > 2-2) Maintainability > > Usbfs provides similar interfaces which USB core provides to USB host drives. To use the interfaces in user space, implementation which are included in some portions of usbip_host.ko, vhci_hcd.ko and usbip_core should be moved to userspace. At the same time, utilities must be modified. Interfaces used between the utilities and the kernel modules (sysfs) will be changed to function calls in userspace. > > For example, I'd like to break down usbip_host.ko down as below. > (a) submits and cancels URBs to USB core > (b) core part: receives and handle URBs, manage submitted URBs, etc. > (c) provides functions to utilities via sysfs > (d) calls usbip_common's functions > (e) calls kernel functions > > To move it to user space, > (a) replace with usbfs calls > (b) copy the core part > (c) modify to interface inside userspace or use usbfs directly > (d) port some portion of usbip_core > (e) replace with systemcalls and libraries. > > Then, to use usbfs (a), another usbip_host like program which has same for (b) and different in (c), (d) and (e). By (c), utilities should be changed unless sysfs emulation is not provided. > > I think it's better to use the kernel modules as-is. Strictly, it's almost as-is because I put a small code to make replaceable kernel_sendmsg() and kernel_recvmsg(). > > As a reference, I stored my prototype including userspace usbip_host with libusb(not sysfs but a portable wrapper of sysfs) in staging/usbip of linux 3.14.2. It still needs refactoring. > https://drive.google.com/drive/folders/0BxnuWBW_tB9NflFDY1hlcVBRNEd4ZzB2VFJ3OTI0REFGelNBV2xXTHRNc0lReGJlaTRGdDQ/0BxnuWBW_tB9NfjhabzVMSnZ6VGxrTXBwNEE1dFJYdENvaC1IMUg1ZG1kTU9iOUN1OEpGUlU > In the prototype, libsrc/stub_main.c, stub_dev.c, stub_rx.c and stub_tx.c are portings of usbip_host. stub_common.c and stub_event.c is usbip_core. Macro USE_LIBUSB in utilities denotes portions to be modified in utilities. > > Getting off the point, I'm trying to make cross-platform usbip_host with libusb. It may has less relationship to kernel. > > 3) About SSL patch > > > And there have been previous patches to add openssl support for usbip, but > > do so in a much different way from this patch set. Is that the primary > > reason you did this work, or do you have some other goal / requirement with > > usbip that caused you to create this design? > > I'm sorry. I just didn't know the previous patch because I'm new to the mailing list. > For my requirement, my SSL patches(08/13 and 09/13) are not needed. I need Secure WebSocket (wss:) but it's covered by 13/13. The older patches are on the mailing list, dig through the archives to find them. > Could I remove them from V2? > > And, please, let me know the reference of the previous SSL patch because I couldn't search in the linux-usb mail archive. I will study it and send my SSL patch later if it has some other effect. Why do you need / want websockets here? I don't think that question was really answered. Why doesn't the existing functionality work properly for you to require changing the transmission layer? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
