Dear Greg,
Thank you for your great help.
> Can you please fix it up and resend?
Very sorry. I struggled with my corporate mail system.
I hope word wrapping works well.
> Also, please resend your patches, based on linux-next, with
> the previous fixes mentioned, so that I can consider your patches to
> be merged.
My pleasure.
> I don't think that question was really answered.
Sorry. I misread that your question ('this work') was about SSL.
> Why do you need / want websockets here?
WebSocket is needed for USB/IP in internet.
Linux is the most popular cloud platform and promising distributed
ubiquitous controller platform. USB is the most popular device.
And USB/IP is wonderful because application/subsystem can handle remote
devices as if local devices without any modification to host diver and
application/subsystem. Plug-and-play too.
Assumed use case is a system that cloud service serves distributes
devices in home and corporate office networks.
Home/SOHO/Intranet Internet
+--------+ +--------+
+------+ +------+ |Router, | |Cloud |
+|device|---|Linux |-----|Proxy, |------------|Service |
|+------+ +------+ |Firewall| |on Linux|
+------+ +--------+ +--------+
ex)
sensors .................................... environment analysis
cameras .................................... monitoring, recording
ID/biometric readers ....................... authentication
WebSocket is widely used to encapsulate packets in HTTP and to carry
them through firewall using HTTP port numbers.
Not only cloud-to-distributed-devices, WebSocket may be effective in
intranet including firewalls, multi-VMs with IP filtering.
In these days, IoT - internet of things is one of a buzzword. I think
USB over WebSocket may covers some cases.
I had to write the reason to introduce WebSocket in the cover letter so
I will add to V2.
> Why do you need host side as well?
I don't have other reason than maintainability written in previous
e-mail. Please, forgive me to repeat it.
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 and usbip_core should be
copied to userspace. At the same time, utilities must be modified
because 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 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_tB9NflFDY1hlcVBRNEd4ZzB2
VFJ3OTI0REFGelNBV2xXTHRNc0lReGJlaTRGdDQ/0BxnuWBW_tB9NfjhabzVMSnZ6VGxrTXB
wNEE1dFJYdENvaC1IMUg1ZG1kTU9iOUN1OEpGUlU
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.
My patch works in both host and vhci side using existing kernel modules.
> Why doesn't the existing functionality work properly for you to
require changing the transmission layer?
I need API to make easy to apply application layer protocols to TCP/IP
transmission. There are many open sources supporting application
protocols in userspace. So the API must be in userspace.
In my case, not only WebSocket but also DNS and connection
establishment via HTTP-proxy are needed. Also, extensibility to other
application protocols is valuable in the future. I'm not sure whether
it's valuable or not, for example, USB over SIP/VoIP can be applied.
Regarding file system, fuse allows to implement and debug file systems
in userspace easily. EncFS on fuse appeared first and crypt-dm on
device mapper next. I think userspace extensibility is valuable at
least for the migration.
I hope someone wants the USB/IP userspace application protocol
extensibility too.
For myself, the WebSocket patch (13/13) itself is not necessary to be
merged into kernel. The patches provide the APIs (01/13 to 12/13
excluding SSL:08/13 and 09/13) are needed to be merged. But I thought
the WebSocket patch helps to explain the needs of the extensibility, it
is acceptable in tools directory and there must be someone else who has
interest IoT by USB over WebSocket.
Thanks,
n.iwata
//
> -----Original Message-----
> From: Greg KH [mailto:greg@xxxxxxxxx]
> Sent: Friday, April 10, 2015 9:00 PM
> To: fx IWATA NOBUO
> Cc: valentina.manea.m@xxxxxxxxx; shuah.kh@xxxxxxxxxxx;
> linux-usb@xxxxxxxxxxxxxxx; fx MICHIMURA TADAO
> Subject: Re: [PATCH 04/13] USB/IP: kernel module for userspace URBs
> transmission
>
> 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_tB9NflFDY1hlcVBRNEd4Zz
> >
> B2VFJ3OTI0REFGelNBV2xXTHRNc0lReGJlaTRGdDQ/0BxnuWBW_tB9NfjhabzVMSnZ6VGx
> > rTXBwNEE1dFJYdENvaC1IMUg1ZG1kTU9iOUN1OEpGUlU
> > 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
