Hi,
On 04/28/2015 11:35 AM, fx IWATA NOBUO wrote:
Hello,
As far as I understand your design you have kernel stub driver which
is sending and receiving data via socket fd received from userspace.
Now after this series you are exporting all messages to userspace
where daemon is sending them using web sockets. Am I right?
Yes.
I don't see what are the benefits of such kernel driver?
Couldn't you just simply use libusb in your daemon and do everything
from userspace? Such solution could be beneficial for older kernel
because you don't need to backport your patches but simply use your
daemon which will be compatible with most kernel versions as libusb is
working with them.
Sorry repeating comment in V1 thread.
I had to write this to change log.
There are 2 reasons.
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.
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 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.
First of all please excuse me that I didn't check list archive for this
question. Really sorry that you had to write it once again.
I see your arguments why not libusb but why couldn't you do this in
userspace by using simple tcp over http or ssh or anything what would
you like to use? It would work out of box without any changes in kernel.
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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
