Hello,
> That doesn't tell me much. I am looking to see in the above where are
> the server and client located.
Sorry. The 'goal' section is added in later version.
I will add reference to ASCII diagram in section 2.
Also improve diagram in section 2.
NEW) - dedicates devices from device(stub)-side
(client) (server)
+------+ +------------------+
device--+ STUB | | application/VHCI |
+------+ +------------------+
1) usbipa ... start daemon
= = =
2) usbip list --local
3) usbip connect --- export a device ------>
= = =
4) usbip disconnect --- un-export a device --->
> >> Is this something that could be solved by opening ports in the
> >> firewall?
> > Usually, http(80) and https(443) from inside is opened for internet
> > Access.
> You can open other ports if need be and if you have access to firewall.
> Doesn't making sure port 3240 isn't blocked on the firewall help?
If it's the firewall of personal workstation, it's possible.
> > The firewall is in between internet and <intranet, soho, home, etc.>
As far as I know, corporate firewall is prohibited to open port access
from outside by system administrator.
For home network, I think rarely open port from outside.
Enterprise/SOHO/Home Firewall/Proxy/Router Internet
EXISTING)
APP# usbip attach -----------(passed)--------> DEV# usbipd
DEV# usbipd (blocked)|| <--------- APP# usbip attach
NEW)
DEV# usbip connect ----------(passed)--------> DEV# usbipa
APP# usbipa (blocked)|| <--------- APP# usbip connect
> I want to understand how a different server (system that doesn't have
> the USB device physically attached) can be authorized to export
> devices that don't belong to it.
1) Connection level security
TCP wrappers allows and/or denies network access. It is enabled when the
daemons are compiled with ./configure --with-tcp-wrappers.
When the daemons are running with SSL or Secure WebSocket tunneling
proxy, the proxy can use client authentication with certificate files.
2) Device level security
Udev rules can allow only known devices. To identify whether a device is
remote, the local bus-id (KERNEL parameter in the rule) will be found in
the last column of /sys/devices/platform/vhci_hcd/status[.N]. When
device is found, the port number of USB/IP can be found in the first
column of the matched line. The udev script can finish the connection
using detach operation with the port number.
I know that it's problem that the daemon accept any connected remote
devices unless something special described above.
User (or administrator) using new daemon must be careful.
While applying the system, I learned server edition linux is different
from workstation. In workstation edition, most of all devices are plug-
and-playable. But, in server edition, there's less USB configuration.
So administrator will do something to enable USB device.
> Something about this model doesn't sound right. If I have system that
> sits behind a firewall, I don't want USB devices visible to anybody
> and everybody. I don't see anything in this series that disallows
> that, short of saying don't enable USB/IP.
The current (bind-and-attach) operation and new (connect) operation is
independent. New operation is available when administrator starts new
daemon.
Please, let me know if you have comments to goal #2.
---
1-2) To improve usability of operations
When two Linux machines are in a small distance, it's OK to bind (makes
importable) at device side machine and attach (import) at application
side. If application is as cloud service or in blade server, it's not
practical to attach from application side. It's useful to connect
(export) from device side. This patch set adds the new operation to
connect from device side.
---
> I would like to know why there is a need to change the existing server-
> client model. I still would like to see a concrete answer why the
> current model doesn't work.
I don't have reason other than direction of connection from outside from
firewall.
My motivation is to utilize USB/IP as a platform of IoT.
Linux is major of server OS and various small linux node is distributed
everywhere. USB devices are most easy-to-use for the small node.
USB/IP is useful to serve USB devices of distributed linux nodes as if
they are local devices without any modification to applications.
My goal is add flexibility for the IoT system. As a user of USB/IP, I
think new way (connect) helps to handle many USB devices of many
distributed linux nodes.
> btw: could you please re-run get_maintainers - my email address in the
> MAINTAINERS file changed a while ago. I think your email might be
> outdated.
I did.
Sorry for my late response. I took time to write the answer.
Thank you for taking time,
n.iwata
//
> -----Original Message-----
> From: Shuah Khan [mailto:shuah...@samsung.com]
> Sent: Saturday, December 03, 2016 12:49 AM
> To: fx IWATA NOBUO; valentina.mane...@gmail.com;
> gre...@linuxfoundation.org; linux-usb@vger.kernel.org
> Cc: fx MICHIMURA TADAO; Shuah Khan; Shuah Khan
> Subject: Re: [PATCH v13 00/10] usbip: exporting devices
>
> On 12/02/2016 02:38 AM, fx IWATA NOBUO wrote:
> > Hello,
> >
> >> I am not clear on this. Is Client and server behind different
> >> firewalls?
> >
> > No.
> > The firewall is in between internet and <intranet, soho, home, etc.>
> >
> >> So the above doesn't apply to a) and it works?
> >
> > Yes.
> >
> >> What does this mean? Why is this connection from outside?
> >
> > 'usbip attach -r' tries to establish connection.
>
> That doesn't tell me much. I am looking to see in the above where are the
> server and client located.
>
> >
> >> Is this something that could be solved by opening ports in the
> >> firewall?
> > Usually, http(80) and https(443) from inside is opened for internet
> > Access.
>
> You can open other ports if need be and if you have access to firewall.
>
> >
> >
> >> Can we use server and client terminology which is we use in instead
> >> of App and Dev.
> >
> > In https://www.kernel.org/doc/readme/tools-usb-usbip-README, I
> > couldn't find the definition.
> >
> > Do you mean 'server' is a linux machine which has devices or linux
> > machine which runs server daemon?
> >
> > In existing way, they are same.
>
> Yes. Server is the system with the USB device physically attached to.
>
> >
> > In new way, they are not.
> > The linux machine which has device doesn't have server daemon.
>
> Okay this is a big change and that isn't very clear in any of the change
> logs. This is one of my concerns with the patch series.
>
> I want to understand how a different server (system that doesn't have the
> USB device physically attached) can be authorized to export devices that
> don't belong to it. Something about this model doesn't sound right. If I
> have system that sits behind a firewall, I don't want USB devices visible
> to anybody and everybody. I don't see anything in this series that disallows
> that, short of saying don't enable USB/IP.
>
> I would like to know why there is a need to change the existing server-client
> model. I still would like to see a concrete answer why the current model
> doesn't work.
>
> Doesn't making sure port 3240 isn't blocked on the firewall help?
>
> btw: could you please re-run get_maintainers - my email address in the
> MAINTAINERS file changed a while ago. I think your email might be outdated.
>
> thanks,
> -- Shuah
>
> >
> > I'd like to confirm the definition to answer rest of questions.
> >
> > Best Regards,
> >
> > n.iwata
> > //
> >> -----Original Message-----
> >> From: Shuah Khan [mailto:shuah...@samsung.com]
> >> Sent: Friday, December 02, 2016 9:39 AM
> >> To: fx IWATA NOBUO; valentina.mane...@gmail.com;
> >> gre...@linuxfoundation.org; linux-usb@vger.kernel.org
> >> Cc: fx MICHIMURA TADAO; Shuah Khan
> >> Subject: Re: [PATCH v13 00/10] usbip: exporting devices
> >>
> >> On 11/23/2016 10:01 PM, fx IWATA NOBUO wrote:
> >>> Hello,
> >>>
> >> Looks like you removed the text. Let's go back to the goals.
> >> Can we use server and client terminology which is we use in instead
> >> of App and Dev. It makes lot easier to understand.
> >>
> >> https://www.kernel.org/doc/readme/tools-usb-usbip-README
> >>
> >>>> 1. Goal
> >>
> >>>> 1-1) To give flexibility to direction of connection Using USB/IP in
> >>>> internet, there can be two cases.
> >>>> a) an application is inside firewall and devices are outside.
> >>
> >> This is the case Client is behind firewall and server is outside the
> >> firewall.
> >>
> >>>> b) devices are inside firewall and an application is inside.
> >>
> >> I am not clear on this. Is Client and server behind different firewalls?
> >>
> >>>> In case-a, import works because the connection is from inside.
> >>
> >>> EXISTING)
> >>> APP# usbip attach -----------(passed)--------> DEV# usbipd
> >>> DEV# usbipd (blocked)|| <--------- APP# usbip attach
> >>
> >> So the above doesn't apply to a) and it works?
> >>
> >>>> In case-b, import doesn't works because the connection is from outside.
> >>
> >> What does this mean? Why is this connection from outside?
> >>
> >>>> Connection from device side is needed. This patch set adds the
> >>>> direction of connection establishment.
> >>
> >> Is this something that could be solved by opening ports in the firewall?
> >>
> >>
> >>>> Can you elaborate on the use-case a bit more? What does it mean to
> >>>> "Connection from device side is needed"?
> >>>
> >>> I'd like to update ending part of use case as following.
> >>> ---
> >>> Firewall, proxy, or router in front of internet usually blocks
> >>> connections from internet regarding all TCP ports. They opens some
> >>> ports, usually HTTP(80) and HTTPS(443), for connection from inside.
> >>> In combination with WebSocket proxy, USB/IP can establish connection
> >>> from inside of the firewall.
> >>>
> >>> Enterprise/SOHO/Home Firewall/Proxy/Router Internet
> >>>
> >>> EXISTING)
> >>> APP# usbip attach -----------(passed)--------> DEV# usbipd
> >>> DEV# usbipd (blocked)|| <--------- APP# usbip attach
> >>>
> >>> NEW)
> >>> DEV# usbip connect ----------(passed)--------> DEV# usbipa
> >>> APP# usbipa (blocked)|| <--------- APP# usbip connect
> >>>
> >>> Attach operation can invite devices in internet but cannot invite
> >>> devices from internet. On the other hand, connect operation can
> >>> dedicate devices to internet but cannot dedicate devices in internet.
> >>
> >> The above isn't very clear. Do you mean to say, client can find
> >> devices exported by a server? When you say Internet how many servers
> >> are we looking at? Random servers or known servers?
> >>
> >> Current USB/IP use-cases are:
> >>
> >> - Server could export USB devices to virtual machines running on it.
> >> Access is confined and limited to that one system.
> >> - Server could export USB devices and clients as long as no firewalls
> >> in between.
> >>
> >> In the above two models, user has permissions to use server and client.
> >> In this new proposed model, how does this work? Who sets up the
> >> server to export or push exports to clients. How does server know
> >> which clients to push exports to?
> >>
> >> With a feature like this, it is important to understand the use-cases
> >> in detail.
> >>
> >> thanks,
> >> -- Shuah
> >>
> >>> ---
> >>>
> >>>> I would like to see server side and client side operations clearly.
> >>>> It would help me understand the use-case you are trying to add.
> >>>
> >>> It's shown in README and manual page added by patch 9/10 as below.
> >>>
> >>> app:# insmod usbip-core.ko
> >>> app:# insmod vhci-hcd.ko
> >>>
> >>> app:# usbipa -D
> >>> - Start usbip daemon.
> >>>
> >>> dev:# (Physically attach your USB device.)
> >>>
> >>> dev:# insmod usbip-core.ko
> >>> dev:# insmod usbip-host.ko
> >>>
> >>> dev:# usbip list -l
> >>> - List driver assignments for USB devices and their busid.
> >>>
> >>> dev:# usbip connect --remote <host> --busid <busid>
> >>> - Bind usbip-host.ko to the device with <busid>.
> >>> - The USB device of <busid> is connected to remote host!
> >>>
> >>> dev:# usbip disconnect --remote <host> --busid <busid>
> >>> - The USB device with <busid> is disconnected from remote host.
> >>> - Unbind usbip-host.ko from the device.
> >>>
> >>>> I do have some concerns about security on client side. User sits on
> >>>> the client side and it should be a pull from client side as opposed
> >>>> to push from server side.
> >>>
> >>> Connection level consideration is described in "5. Security
> >>> Consideration". As you know, USB/IP already has TCP wrapper option.
> >>> With SSL or WebSocket(wss) tunneling proxy, client authentication
> >>> can be applied using the proxies.
> >>>
> >>> I didn't write device level consideration. It's same as local device
> >>> plug-and-play. I will add description below in cover letter and README.
> >>>
> >>> ---
> >>> Udev rules can allow only known devices. To identify a device is
> >>> remote, the local bus-id (KERNEL parameter in the rule) will be
> >>> found the last in column of
> >>> /sys/devices/platform/vhci_hcd/status[.N]. When device is found, the
> >>> port number in USB/IP can be found in the first column of the
> >>> matched line. The udev can finish the connection using detach operation
> with the port number.
> >>> ---
> >>>
> >>>> It sounds like this patch series adds push from server side.
> >>>
> >>> Yes.
> >>> But it's only the initiation request and response.
> >>> URBs direction is just same as before. Applications send submit and
> >>> unlink, devices process them.
> >>>
> >>> Your comment is at goal #1. I'm also considering goal #2.
> >>>
> >>> Thanks for reviewing,
> >>>
> >>> nobuo.iwata
> >>> //
> >>>> -----Original Message-----
> >>>> From: Shuah Khan [mailto:shuah...@samsung.com]
> >>>> Sent: Thursday, November 24, 2016 1:43 AM
> >>>> To: fx IWATA NOBUO; valentina.mane...@gmail.com;
> >>>> gre...@linuxfoundation.org; linux-usb@vger.kernel.org
> >>>> Cc: fx MICHIMURA TADAO; Shuah Khan; Shuah Khan
> >>>> Subject: Re: [PATCH v13 00/10] usbip: exporting devices
> >>>>
> >>>> On 11/21/2016 11:48 PM, Nobuo Iwata wrote:
> >>>>> Dear all,
> >>>>>
> >>>>> This series of patches adds exporting device operation to USB/IP.
> >>>>>
> >>>>> NOTE:
> >>>>> This patch set modifies only userspace codes in tools/usb/usbip.
> >>>>>
> >>>>> 1. Goal
> >>>>>
> >>>>> 1-1) To give flexibility to direction of connection Using USB/IP
> >>>>> in internet, there can be two cases.
> >>>>> a) an application is inside firewall and devices are outside.
> >>>>> b) devices are inside firewall and an application is inside.
> >>>>> In case-a, import works because the connection is from inside.
> >>>>> In case-b, import doesn't works because the connection is from
> outside.
> >>>>> Connection from device side is needed. This patch set adds the
> >>>>> direction of connection establishment.
> >>>>>
> >>>>
> >>>> Can you elaborate on the use-case a bit more? What does it mean to
> >>>> "Connection from device side is needed"?
> >>>>
> >>>> I would like to see server side and client side operations clearly.
> >>>> It would help me understand the use-case you are trying to add.
> >>>>
> >>>> I do have some concerns about security on client side. User sits on
> >>>> the client side and it should be a pull from client side as opposed
> >>>> to push from server side.
> >>>>
> >>>> It sounds like this patch series adds push from server side.
> >>>>
> >>>> thanks,
> >>>> -- Shuah
> >>>>
> >>>>> NOTE:
> >>>>> Directions of URBs requests and responses are not changed. Only
> >>>>> direction of connection establishment initiated with usbip command
> >>>>> is added to exsiting one.
> >>>>>
> >>>>> 1-2) To improve usability of operations When two Linux machines
> >>>>> are in a small distance, it's OK to bind (makes
> >>>>> importable) at device side machine and attach (import) at
> >>>>> application side.
> >>>>> If application is as cloud service or in blade server, it's not
> >>>>> practical to attach from application side. It's useful to connect
> >>>>> (export) from device side. This patch set adds the new operation
> >>>>> to connect from device side.
> >>>>>
> >>>>> 2. What's 'exporting' device
> >>>>>
> >>>>> Exporting devices is not new. The request and response PDU have
> >>>>> already been defined in tools/usbip/usbip/src/usbip_network.h.
> >>>>> #/* Export a USB device to a remote host. */
> >>>>> #define OP_EXPORT 0x06
> >>>>> #define OP_REQ_EXPORT (OP_REQUEST | OP_EXPORT)
> >>>>> #define OP_REP_EXPORT (OP_REPLY | OP_EXPORT)
> >>>>> # struct op_export_request
> >>>>> # struct op_export_reply
> >>>>> #/* un-Export a USB device from a remote host. */
> >>>>> #define OP_UNEXPORT 0x07
> >>>>> #define OP_REQ_UNEXPORT (OP_REQUEST | OP_UNEXPORT)
> >>>>> #define OP_REP_UNEXPORT (OP_REPLY | OP_UNEXPORT)
> >>>>> # struct op_unexport_request
> >>>>> # struct op_unexport_reply
> >>>>>
> >>>>> But they have not been used yet. This series adds new operations:
> >>>>> 'connect' and 'disconnect' using these PDUs.
> >>>>>
> >>>>> EXISTING) - invites devices from application(vhci)-side
> >>>>> +------+
> >>>> +------------------+
> >>>>> device--+ STUB | |
> application/VHCI
> >> |
> >>>>> +------+
> >>>> +------------------+
> >>>>> 1) usbipd ... start daemon
> >>>>> = = =
> >>>>> 2) usbip list --local
> >>>>> 3) usbip bind
> >>>>> <--- list bound devices --- 4) usbip list
> >> --remote
> >>>>> <--- import a device ------ 5) usbip attach
> >>>>> = = =
> >>>>> X disconnected 6) usbip detach
> >>>>> 7) usbip unbind
> >>>>>
> >>>>> NEW) - dedicates devices from device(stb)-side
> >>>>> +------+
> >>>> +------------------+
> >>>>> device--+ STUB | |
> application/VHCI
> >> |
> >>>>> +------+
> >>>> +------------------+
> >>>>> 1) usbipa ... start
> >>>>> daemon = = =
> >>>>> 2) usbip list --local
> >>>>> 3) usbip connect --- export a device ------>
> >>>>> = = =
> >>>>> 4) usbip disconnect --- un-export a device --->
> >>>>>
> >>>>> Bind and unbind are done in connect and disconnect internally.
> >>>>>
> >>>>> 3. The use cases
> >>>>>
> >>>>> EXISTING)
> >>>>>
> >>>>> In existing way, computers in small distance, having same user
> >>>>> account, can be easily managed by a same user. Bind in local
> >>>>> machine and attach in remote machine by the user. The devices can
> >>>>> be exporsed automatically in the local machine, for example, at
> >>>>> strat up. They can be attached from remote.
> >>>>>
> >>>>> When there are distributes linux nodes with USB devices in
> >>>>> internet, they are exposed by bind operation at start up, server
> >>>>> behind firewall can list and attach the devices.
> >>>>> Internet
> >>>>> Exposed +----------+ +--------+
> >> +--------+
> >>>>> +------+ |Linux |+ |Router, | |Service
> |
> >>>>> +|device|--|Controller||-------------------|proxy, |----|on
> |
> >>>>> |+------+ +----------+| |firewall| |Linux
> |
> >>>>> +------+ +----------+ +--------+
> +--------+
> >>>>> <--- attach(import)
> >>>>> USB/IP + WS proxy WS proxy +
> >> USB/IP
> >>>>>
> >>>>> NEW)
> >>>>>
> >>>>> Assuming that a server computer which runs application and VHCI is
> >>>>> in a server room and device side machines are small distributed
> >>>>> nodes outside of the server room, the operator of the server
> >>>>> compter is different form the distributed nodes. The server
> >>>>> computer may be in unattended operation. In the new way, after the
> >>>>> daemon has been started, device can be connected with connect
> >>>>> command in the distributed nodes. If the distributed nodes doesn't
> >>>>> have user interface, the connect command can be executed from start
> up procedure.
> >>>>>
> >>>>> In another senario to connect devices to a Linux based cloud
> >>>>> service using WebSocket proxy, it's needed to establish connection
> >>>>> from a device inside of firewall to a service outside. Exporting
> >>>>> is suitable for the senario.
> >>>>>
> >>>>> Home/SOHO/Intranet Internet
> >>>>> +----------+ +--------+
> >> +--------+
> >>>>> +------+ |Linux |+ |Router, |
> |Internet|
> >>>>> +|device|--|Controller||----|proxy, |-------------------|service
> >>>>> +|device|--|Controller||----||
> >>>>> |+------+ +----------+| |firewall| |on
> Linux|
> >>>>> +------+ +----------+ +--------+
> +--------+
> >>>>> connect(export) -->
> >>>>> USB/IP + WS proxy WS proxy +
> >> USB/IP
> >>>>> ex)
> >>>>> Device Service
> >>>>> sensors ......................................... environment
> >>>>> analysis cameras .........................................
> >>>>> monitoring, recording ID/biometric readers
> >>>>> ............................ authentication
> >>>>>
> >>>>> Connection from outside firewall is usually blocked.
> >>>>> So existing import request sent with attach command doesn't work.
> >>>>>
> >>>>> # usbipd (blocked)|| <--------- # usbip attach
> >>>>>
> >>>>> Firewall opens some ports, usually HTTP(80) and HTTPS(443), from
> inside.
> >>>>> Then export request sent with new connect command works.
> >>>>>
> >>>>> # usbip connect -----------------------------> # usbipa
> >>>>> (passed)
> >>>>>
> >>>>> 4. Combination with vUDC
> >>>>>
> >>>>> New operations work with vUDC. --device option specifies vUDC mode
> >>>>> as well as list operaion. With stub, connect and disconnect
> >>>>> execute bind and unbind internally. With vUDC, they do not execute
> >>>>> bind and
> >> unbind.
> >>>>> They are done by UDC interface.
> >>>>>
> >>>>> 5. Security consideration
> >>>>>
> >>>>> When application side daemon is not started, this patch set
> >>>>> doesn't affect exsiting security.
> >>>>>
> >>>>> Daemons accept following requests form network :
> >>>>> EXISTING) 'list --remote' and 'attach'
> >>>>> NEW) 'connect' and 'disconnect'
> >>>>>
> >>>>> TCP wrappers allows and/or denies network access. It is enabled
> >>>>> when the daemons are compiled with ./configure --with-tcp-wrappers.
> >>>>>
> >>>>> When the daemons are running with SSL or Secure WebSocket
> >>>>> tunneling proxy, the proxy can use client authentication with
> certificate files.
> >>>>>
> >>>>> 6. Mixed usage
> >>>>>
> >>>>> Both existing and new way work in same machines simultaneously.
> >>>>> Status of devices and ports are controlled in stub and vhci driver.
> >>>>>
> >>>>> 7. Wording
> >>>>>
> >>>>> Adding the new operation, some inconsistnecies in wording are
> >>>>> appeared in documentation, function name, etc. If needed, they are
> >> fixed.
> >>>>>
> >>>>> 'export' is used for bind and 'exported' is used for bound. They
> >>>>> are changed to 'make importable' and 'imported' respectively. The
> >>>>> words are not new. For example, in the output of port operation,
> >>>>> 'imported devices' is already used.
> >>>>>
> >>>>> 'client' and 'server' are switched between existing and new operation.
> >>>>> Sometimes they implies device-side and application-side. So, words
> >>>>> 'device-side' and 'application-side' are used in documentations as
> >>>>> needed for clarity.
> >>>>>
> >>>>> ---
> >>>>> Version information
> >>>>>
> >>>>> This series is divided from "USB/IP over WebSocket" patch set.
> >>>>> Rest of the set will be sent as another series.
> >>>>>
> >>>>> v13)
> >>>>> # Recreated based on linux-next 20161117.
> >>>>> # Updated cover letter: added goal, rewrote overview as
> >>>>> explanation of 'exporting' and added that this patch dosn't affect
> >>>>> security condition in existing usage.
> >>>>> # Moved protocol documentation as the last patch.
> >>>>> # Added explanation to each patch.
> >>>>> # Removed copyright from usbip_bind.c, usbip_unbind.c,
> >>>>> usbip_network.h and usb_list.c in which size of modification is
> >>>>> small and functional change is not included.
> >>>>> # Fixed help string about position of --parsable option.
> >>>>>
> >>>>> v12)
> >>>>> # Recreated based on linux-next 20161012.
> >>>>> # Fixed checkpatch a warning about symbolic permission.
> >>>>> # Fixed checkpatch warnings about traling space in a document.
> >>>>>
> >>>>> v11)
> >>>>> # Corrected program name of each daemon which are used in version
> >>>>> string, info messages and daemon name for tcp wrappers.
> >>>>> # Added description about tcp wrappers in security consideration
> >>>>> of cover letter.
> >>>>> # Added security consideration for existing requests in
> >>>>> contradistinction to new requests.
> >>>>> # Recreated based on linux-next 20160928.
> >>>>>
> >>>>> v10)
> >>>>> # Recreated based on linux-next 20160810.
> >>>>>
> >>>>> v9)
> >>>>> # Moved a set_nodelay() from usbipd_dev.c to usbipd.c to affect
> >>>>> both device side and application side daemon.
> >>>>> # Removed redundant blank line at the end of files.
> >>>>>
> >>>>> v8)
> >>>>> # Divided into smaller patches.
> >>>>> # Excluded low-related patches.
> >>>>> # Improved change log.
> >>>>> # Changed info level logs in usbip_ux.c to debug level logs.
> >>>>> # Added options to vUDC.
> >>>>> # Tested with vUDC.
> >>>>>
> >>>>> v7)
> >>>>> # Removed userspace transmission and WebSocket command/daemon.
> >>>>> # Fixed checkpatch errors and warnings.
> >>>>>
> >>>>> v6)
> >>>>> # Added __rcu annotation to a RCU pointer to clear sparse warnings.
> >>>>> # Corrected a copy to RCU pointer with rcu_rcu_assign_pointer().
> >>>>> # Added __user annotations to arguments of read/write method.
> >>>>> # Added static to some functions which are not called from other files.
> >>>>> # Removed unnecessary EXPORT_SYMBOLs.
> >>>>>
> >>>>> v5)
> >>>>> # Added vendor/pruduct name conversion to port command.
> >>>>> # Put initial value to pool_head in name.c.
> >>>>> # Fixed list command exception when host option is omitted.
> >>>>> # Fixed exception in case gai_strerror() returns NULL.
> >>>>> # Fixed WebSocket connection close via proxy.
> >>>>> # Fixed to stop WebSocket ping-pong on connection close.
> >>>>> # Removed redundant usbipd daemon option.
> >>>>> # Removed redundant SSL code had not been deleted.
> >>>>> # Removed an unused local variable in WebSocket code.
> >>>>> # Modified C++ reserved word in names.c as same as headers.
> >>>>>
> >>>>> v4)
> >>>>> # Fixed regression of usbip list --remote
> >>>>>
> >>>>> v3)
> >>>>> # Coding style for goto err labels are fixed.
> >>>>> # Defined magic numbers for open_hc_device() argument.
> >>>>> # Corrected include .../uapi/linux/usbip_ux.h as
> <linux/usbip_ux.h>.
> >>>>> # Modified parameter notation in manuals not to use '='.
> >>>>> # Fixed inappropriate version definition in
> >>>>> tools/.../websocket/configure.ac.
> >>>>> # Remved unnecessary COPYING and AUTHORS fil from
> tools/.../websocket/.
> >>>>> # Added -version-info to libraries in tools/.../src.
> >>>>>
> >>>>> v2)
> >>>>> # Formatted patches from linux-next.
> >>>>> # Fixed change log word wrapping.
> >>>>> # Removed SSL patches.
> >>>>> # Fixed a bug that vendor and product names are not shown by
> >>>>> 'usbws list -l' because usbip_names_init() was not called in
> libusbip.la.
> >>>>>
> >>>>> Thank you,
> >>>>>
> >>>>> Nobuo Iwata <nobuo.iw...@fujixerox.co.jp> //
> >>>>>
> >>>>> *** BLURB HERE ***
> >>>>>
> >>>>> Nobuo Iwata (10):
> >>>>> usbip: exporting devices: modifications to network header
> >>>>> usbip: exporting devices: modifications to host side libraries
> >>>>> usbip: exporting devices: new connect operation
> >>>>> usbip: exporting devices: new disconnect operation
> >>>>> usbip: exporting devices: modifications to daemon
> >>>>> usbip: exporting devices: modifications to attach and detach
> >>>>> usbip: exporting devices: new application-side daemon
> >>>>> usbip: exporting devices: change to usbip_list.c
> >>>>> usbip: exporting devices: chage to documenattion
> >>>>> usbip: exporting devices: modifications to protocol text
> >>>>>
> >>>>> Documentation/usb/usbip_protocol.txt | 204
> ++++++++++++++--
> >>>>> tools/usb/usbip/Makefile.am | 2 +-
> >>>>> tools/usb/usbip/README | 70 ++++--
> >>>>> tools/usb/usbip/doc/usbip.8 | 136 +++++++++--
> >>>>> tools/usb/usbip/doc/usbipa.8 | 78 +++++++
> >>>>> tools/usb/usbip/doc/usbipd.8 | 38 +--
> >>>>> tools/usb/usbip/libsrc/usbip_host_common.c | 6 +-
> >>>>> tools/usb/usbip/libsrc/usbip_host_common.h | 8 +-
> >>>>> tools/usb/usbip/libsrc/vhci_driver.c | 118 ++++++++--
> >>>>> tools/usb/usbip/libsrc/vhci_driver.h | 7 +-
> >>>>> tools/usb/usbip/src/Makefile.am | 12 +-
> >>>>> tools/usb/usbip/src/usbip.c | 15 +-
> >>>>> tools/usb/usbip/src/usbip.h | 10 +-
> >>>>> tools/usb/usbip/src/usbip_attach.c | 50 +---
> >>>>> tools/usb/usbip/src/usbip_bind.c | 4 +-
> >>>>> tools/usb/usbip/src/usbip_connect.c | 228
> >> ++++++++++++++++++
> >>>>> tools/usb/usbip/src/usbip_detach.c | 13 +-
> >>>>> tools/usb/usbip/src/usbip_disconnect.c | 215
> +++++++++++++++++
> >>>>> tools/usb/usbip/src/usbip_list.c | 17 +-
> >>>>> tools/usb/usbip/src/usbip_network.h | 4 +-
> >>>>> tools/usb/usbip/src/usbip_unbind.c | 4 +-
> >>>>> tools/usb/usbip/src/usbipd.c | 258
> >>>> +++------------------
> >>>>> tools/usb/usbip/src/usbipd.h | 39 ++++
> >>>>> tools/usb/usbip/src/usbipd_app.c | 242
> >> +++++++++++++++++++
> >>>>> tools/usb/usbip/src/usbipd_dev.c | 252
> >>>> ++++++++++++++++++++
> >>>>> 25 files changed, 1631 insertions(+), 399 deletions(-) create
> >>>>> mode
> >>>>> 100644 tools/usb/usbip/doc/usbipa.8 create mode 100644
> >>>>> tools/usb/usbip/src/usbip_connect.c
> >>>>> create mode 100644 tools/usb/usbip/src/usbip_disconnect.c
> >>>>> create mode 100644 tools/usb/usbip/src/usbipd.h create mode
> >>>>> 100644 tools/usb/usbip/src/usbipd_app.c create mode 100644
> >>>>> tools/usb/usbip/src/usbipd_dev.c
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Shuah Khan
> >>>> Sr. Linux Kernel Developer
> >>>> Open Source Innovation Group
> >>>> Samsung Research America(Silicon Valley) shuah...@samsung.com
> >>>
> >>
> >>
> >> --
> >> Shuah Khan
> >> Sr. Linux Kernel Developer
> >> Open Source Innovation Group
> >> Samsung Research America(Silicon Valley) shuah...@samsung.com
> >
>
>
> --
> Shuah Khan
> Sr. Linux Kernel Developer
> Open Source Innovation Group
> Samsung Research America(Silicon Valley) shuah...@samsung.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
