usbip-devel Mailing List for The USB/IP Project (Page 6)
Status: Alpha
Brought to you by:
hirofuchi
Menu
▾
▴
usbip-devel — usbip developers mailing list
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2007 |
Jan
(9) |
Feb
|
Mar
(5) |
Apr
|
May
(3) |
Jun
(4) |
Jul
(8) |
Aug
(7) |
Sep
(6) |
Oct
|
Nov
(5) |
Dec
(10) |
| 2008 |
Jan
(2) |
Feb
(2) |
Mar
(1) |
Apr
(30) |
May
(26) |
Jun
(12) |
Jul
(26) |
Aug
(14) |
Sep
(20) |
Oct
(9) |
Nov
(19) |
Dec
(36) |
| 2009 |
Jan
(16) |
Feb
(18) |
Mar
(18) |
Apr
(24) |
May
(52) |
Jun
(69) |
Jul
(44) |
Aug
(12) |
Sep
(9) |
Oct
(1) |
Nov
(3) |
Dec
(4) |
| 2010 |
Jan
(12) |
Feb
(34) |
Mar
(6) |
Apr
(14) |
May
(9) |
Jun
(33) |
Jul
(18) |
Aug
(8) |
Sep
(3) |
Oct
(3) |
Nov
|
Dec
(8) |
| 2011 |
Jan
(11) |
Feb
(11) |
Mar
(18) |
Apr
(10) |
May
(69) |
Jun
(22) |
Jul
(11) |
Aug
(12) |
Sep
(13) |
Oct
(10) |
Nov
(2) |
Dec
(4) |
| 2012 |
Jan
(13) |
Feb
(5) |
Mar
(16) |
Apr
(21) |
May
(8) |
Jun
(10) |
Jul
(1) |
Aug
(2) |
Sep
(2) |
Oct
(17) |
Nov
(4) |
Dec
(2) |
| 2013 |
Jan
|
Feb
(19) |
Mar
(5) |
Apr
(22) |
May
(4) |
Jun
(5) |
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2014 |
Jan
(3) |
Feb
(8) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(5) |
Nov
(1) |
Dec
|
| 2015 |
Jan
(5) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
(3) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Craig P. <cr...@be...> - 2012-04-22 01:02:04
|
Sachindranath, Have you used the client from subversion - https://usbip.svn.sourceforge.net/svnroot/usbip/windows/trunk What are the patches you have applied to pnp.c? Can you further expand on what 'not working' means? What are the error messages? Regards, Craig On 20/04/2012 7:54 PM, sachindranath pv wrote: > Hello, > > I have kernel 3.1.6 . The USBIP for server and client > works perfectly in both linux machines. But in Windows client , its > not working . i already applied the patches to pnp.c . > > Regards > Sachindranath > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > usbip-devel mailing list > usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbip-devel > |
|
From: sachindranath pv <lin...@gm...> - 2012-04-20 10:24:11
|
Hello,
I have kernel 3.1.6 . The USBIP for server and client
works perfectly in both linux machines. But in Windows client , its
not working . i already applied the patches to pnp.c .
Regards
Sachindranath
|
|
From: Alexander T. <ale...@es...> - 2012-04-13 12:16:41
|
I have not been using USB/IP for a while but as far as I can remember, a problem with isochronous devices (like sound cards) has only recently been corrected on the Linux side, but not in the Windows driver. To make any device that uses sound or video work between Linux and Windows, the same fix as was applied to the Linux code will need to be ported to the Windows code. Alexander On Fri, Apr 13, 2012 at 1:40 PM, Roger Tinembart <tin...@br...> wrote: > Hi Linard > > Thanks for the information and your support. > >> ID 046d:0a0b Logitech, Inc. ClearChat Pro USB (USB Headset) >> * On first try: BSOD on the machine where the windows client is running >> * On second try: Gets registered in Device Manager as >> - Sound, video and game controllers - USB Device Over IP >> * But software programs like Skype or the Windows Volume Mixer are not picking up the device. > > I did not try to build the project, I just tried to use the precompiled images available under ubuntu as server and the signed windows driver on a Win7-64 bit PC. I was testing it with a software defined radio (SDR) which is behaving like a USB-Soundcard. I never got it to work, and every second time I also had a BSOD on my PC-client. I remember that about half a year ago, another user tried it with a real USB soundcard and also suffered from BSOD's. So I think there is a general problem in using the usbip windows-driver together with sound-devices. > > Regards, Roger > > -----Ursprüngliche Nachricht----- > Von: Linard Verstraete [mailto:lin...@te...] > Gesendet: Freitag, 13. April 2012 12:44 > An: usb...@li... > Betreff: Re: [usbip-devel] Development Update - April 2012 > > Hi, > > Each week since March I'm investing a few hours to get a USBIP toolchain running on some local machines. It took me some time to figure out how to get the compatible linux kernel modules running and compiling the userspace application. But just since today I also got the windows driver and the windows userspace application running. > > Since you requested some feedback, I took some devices and tested them for the first time: > > ID 090c:1000 Silicon Motion, Inc. - Taiwan (USB Stick) > * Works > > ID 046d:c03f Logitech, Inc. M-BT85 [UltraX Optical Mouse] (USB Mouse) > * Works but noticable lag (RTT to server is <1ms so I'm not sure this is > expected) > > ID 046d:0a0b Logitech, Inc. ClearChat Pro USB (USB Headset) > * On first try: BSOD on the machine where the windows client is running > * On second try: Gets registered in Device Manager as > - Sound, video and game controllers - USB Device Over IP > * But software programs like Skype or the Windows Volume Mixer are not picking up the device. > > ID 04e8:6860 Samsung Electronics Co., Ltd GT-I9100 Phone [Galaxy S II] (Android Tablet, which is actually a Galaxy Tab 7.0 Plus but oke) > * Gets registered in Device Manager as > - SAMSUNG Android Phone - SAMSUNG Android ADB Interface > - Universal Serial Bus controllers - SAMSUNG Mobile USB Composite Device > - Portable Devices - SAMSUNG Mobile MTP Device (This device cannot start (Code 10)) > * The adb.exe process doesn't see the device, so I can't use it to deploy apps to / debug / monitor / ... the device > > Also something that I noticed is that everytime I try to detach with: > 'usbip -D -d 192.168.33.9 1' the following message is displayed, but nothing seems to go wrong... > usbip err: usbip_windows.c: 634 (dev_read_completed) get overlapping > failed: 1167 > > So that's all the feedback I currently have. I hope it's useful for you guys and if there any questions or requests, mail them I will see what I can do. Any tips on how to get the Android working would be greatly appreciated. > > Best regards, > Linard Verstraete. > > On 12/04/2012 14:04, Craig Peacock wrote: >> >> Over the past two weeks with the help of Arjan Mels and Ricardo Gomes >> da Silva there has been an attempt to bring the Windows USBIP driver >> and userspace application up to date. This has involved the >> re-arranging the repository and the checking in of a handful of >> bugs/patches. Thanks to everyone who has submitted patches. >> >> Located in the SVN windows trunk at >> https://usbip.svn.sourceforge.net/svnroot/usbip/windows/trunk is two >> folders. One contains the windows driver and the other contains the >> windows userspace application. >> >> If you are using your own patched versions of USBIP, I would encourage >> you to checkout the code from SVN and provide us some feedback on its >> reliability. If there are any bugs we have missed, can you please >> submit a patch and/or description to this list. >> >> Subject to reasonably positive feedback, we aim to get the driver >> signed and release it as compiled binaries. >> >> Regards, >> >> Craig >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >> -------- For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> >> >> >> _______________________________________________ >> usbip-devel mailing list >> usb...@li... >> https://lists.sourceforge.net/lists/listinfo/usbip-devel > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > usbip-devel mailing list > usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbip-devel > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > usbip-devel mailing list > usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbip-devel -- Alexander Thomas Research Engineer eSATURNUS NV T +32 16 40 12 82 M +32 477 51 63 62 http://www.esaturnus.com |
|
From: Roger T. <tin...@br...> - 2012-04-13 11:40:50
|
Hi Linard Thanks for the information and your support. > ID 046d:0a0b Logitech, Inc. ClearChat Pro USB (USB Headset) > * On first try: BSOD on the machine where the windows client is running > * On second try: Gets registered in Device Manager as > - Sound, video and game controllers - USB Device Over IP > * But software programs like Skype or the Windows Volume Mixer are not picking up the device. I did not try to build the project, I just tried to use the precompiled images available under ubuntu as server and the signed windows driver on a Win7-64 bit PC. I was testing it with a software defined radio (SDR) which is behaving like a USB-Soundcard. I never got it to work, and every second time I also had a BSOD on my PC-client. I remember that about half a year ago, another user tried it with a real USB soundcard and also suffered from BSOD's. So I think there is a general problem in using the usbip windows-driver together with sound-devices. Regards, Roger -----Ursprüngliche Nachricht----- Von: Linard Verstraete [mailto:lin...@te...] Gesendet: Freitag, 13. April 2012 12:44 An: usb...@li... Betreff: Re: [usbip-devel] Development Update - April 2012 Hi, Each week since March I'm investing a few hours to get a USBIP toolchain running on some local machines. It took me some time to figure out how to get the compatible linux kernel modules running and compiling the userspace application. But just since today I also got the windows driver and the windows userspace application running. Since you requested some feedback, I took some devices and tested them for the first time: ID 090c:1000 Silicon Motion, Inc. - Taiwan (USB Stick) * Works ID 046d:c03f Logitech, Inc. M-BT85 [UltraX Optical Mouse] (USB Mouse) * Works but noticable lag (RTT to server is <1ms so I'm not sure this is expected) ID 046d:0a0b Logitech, Inc. ClearChat Pro USB (USB Headset) * On first try: BSOD on the machine where the windows client is running * On second try: Gets registered in Device Manager as - Sound, video and game controllers - USB Device Over IP * But software programs like Skype or the Windows Volume Mixer are not picking up the device. ID 04e8:6860 Samsung Electronics Co., Ltd GT-I9100 Phone [Galaxy S II] (Android Tablet, which is actually a Galaxy Tab 7.0 Plus but oke) * Gets registered in Device Manager as - SAMSUNG Android Phone - SAMSUNG Android ADB Interface - Universal Serial Bus controllers - SAMSUNG Mobile USB Composite Device - Portable Devices - SAMSUNG Mobile MTP Device (This device cannot start (Code 10)) * The adb.exe process doesn't see the device, so I can't use it to deploy apps to / debug / monitor / ... the device Also something that I noticed is that everytime I try to detach with: 'usbip -D -d 192.168.33.9 1' the following message is displayed, but nothing seems to go wrong... usbip err: usbip_windows.c: 634 (dev_read_completed) get overlapping failed: 1167 So that's all the feedback I currently have. I hope it's useful for you guys and if there any questions or requests, mail them I will see what I can do. Any tips on how to get the Android working would be greatly appreciated. Best regards, Linard Verstraete. On 12/04/2012 14:04, Craig Peacock wrote: > > Over the past two weeks with the help of Arjan Mels and Ricardo Gomes > da Silva there has been an attempt to bring the Windows USBIP driver > and userspace application up to date. This has involved the > re-arranging the repository and the checking in of a handful of > bugs/patches. Thanks to everyone who has submitted patches. > > Located in the SVN windows trunk at > https://usbip.svn.sourceforge.net/svnroot/usbip/windows/trunk is two > folders. One contains the windows driver and the other contains the > windows userspace application. > > If you are using your own patched versions of USBIP, I would encourage > you to checkout the code from SVN and provide us some feedback on its > reliability. If there are any bugs we have missed, can you please > submit a patch and/or description to this list. > > Subject to reasonably positive feedback, we aim to get the driver > signed and release it as compiled binaries. > > Regards, > > Craig > > > > > > > > ---------------------------------------------------------------------- > -------- For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > > > > _______________________________________________ > usbip-devel mailing list > usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbip-devel ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ usbip-devel mailing list usb...@li... https://lists.sourceforge.net/lists/listinfo/usbip-devel |
|
From: Linard V. <lin...@te...> - 2012-04-13 11:14:44
|
Hi, Each week since March I'm investing a few hours to get a USBIP toolchain running on some local machines. It took me some time to figure out how to get the compatible linux kernel modules running and compiling the userspace application. But just since today I also got the windows driver and the windows userspace application running. Since you requested some feedback, I took some devices and tested them for the first time: ID 090c:1000 Silicon Motion, Inc. - Taiwan (USB Stick) * Works ID 046d:c03f Logitech, Inc. M-BT85 [UltraX Optical Mouse] (USB Mouse) * Works but noticable lag (RTT to server is <1ms so I'm not sure this is expected) ID 046d:0a0b Logitech, Inc. ClearChat Pro USB (USB Headset) * On first try: BSOD on the machine where the windows client is running * On second try: Gets registered in Device Manager as - Sound, video and game controllers - USB Device Over IP * But software programs like Skype or the Windows Volume Mixer are not picking up the device. ID 04e8:6860 Samsung Electronics Co., Ltd GT-I9100 Phone [Galaxy S II] (Android Tablet, which is actually a Galaxy Tab 7.0 Plus but oke) * Gets registered in Device Manager as - SAMSUNG Android Phone - SAMSUNG Android ADB Interface - Universal Serial Bus controllers - SAMSUNG Mobile USB Composite Device - Portable Devices - SAMSUNG Mobile MTP Device (This device cannot start (Code 10)) * The adb.exe process doesn't see the device, so I can't use it to deploy apps to / debug / monitor / ... the device Also something that I noticed is that everytime I try to detach with: 'usbip -D -d 192.168.33.9 1' the following message is displayed, but nothing seems to go wrong... usbip err: usbip_windows.c: 634 (dev_read_completed) get overlapping failed: 1167 So that's all the feedback I currently have. I hope it's useful for you guys and if there any questions or requests, mail them I will see what I can do. Any tips on how to get the Android working would be greatly appreciated. Best regards, Linard Verstraete. On 12/04/2012 14:04, Craig Peacock wrote: > > Over the past two weeks with the help of Arjan Mels and Ricardo Gomes da > Silva there has been an attempt to bring the Windows USBIP driver and > userspace application up to date. This has involved the re-arranging the > repository and the checking in of a handful of bugs/patches. Thanks to > everyone who has submitted patches. > > Located in the SVN windows trunk at > https://usbip.svn.sourceforge.net/svnroot/usbip/windows/trunk is two > folders. One contains the windows driver and the other contains the > windows userspace application. > > If you are using your own patched versions of USBIP, I would encourage > you to checkout the code from SVN and provide us some feedback on its > reliability. If there are any bugs we have missed, can you please submit > a patch and/or description to this list. > > Subject to reasonably positive feedback, we aim to get the driver signed > and release it as compiled binaries. > > Regards, > > Craig > > > > > > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > > > > _______________________________________________ > usbip-devel mailing list > usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbip-devel |
|
From: Craig P. <cr...@be...> - 2012-04-12 12:03:34
|
Over the past two weeks with the help of Arjan Mels and Ricardo Gomes da Silva there has been an attempt to bring the Windows USBIP driver and userspace application up to date. This has involved the re-arranging the repository and the checking in of a handful of bugs/patches. Thanks to everyone who has submitted patches. Located in the SVN windows trunk at https://usbip.svn.sourceforge.net/svnroot/usbip/windows/trunk is two folders. One contains the windows driver and the other contains the windows userspace application. If you are using your own patched versions of USBIP, I would encourage you to checkout the code from SVN and provide us some feedback on its reliability. If there are any bugs we have missed, can you please submit a patch and/or description to this list. Subject to reasonably positive feedback, we aim to get the driver signed and release it as compiled binaries. Regards, Craig |
|
From: Craig P. <cr...@be...> - 2012-04-03 12:05:32
|
Tim, Thanks for your patches below. I've just checked both into subversion. I still have your 'interface_descriptors_win8' patch to evaluate and submit. I'll do that in the next couple of days. Regards, Craig On 29/03/2012 9:56 PM, Tim Edmonds wrote: > > Attached patch includes two fixes to windows client driver pnp.c: > > 1/ Unset IRP cancel routine on device unplug. Detected by Driver Verifier. > > 2/ Fix iteration over wchar hardware ID string. Fixes occasional BSOD. > > Regards, > > Tim > |
|
From: Ricardo G. da S. <ca...@gm...> - 2012-04-01 17:27:12
|
Craig, Arjan, Well, since some work has been done on the code regarding the library and userspace "splitting", I agree that we probably should keep their codes separated. Maybe with some GUI code we can adapt the solution to hold the 3 projects: the library (everything related to USB/IP protocol and devices), the command-line (current userspace code) and the GUI code (Arjan's code, if allowed and compatible). Maybe the driver should be kept inside the same VS solution too, if possible? After organizing the entire project structure, we should probably start organizing the code itself: inserting comments, refactor, anything that make the code more readable. I believe this could help us to understand the code, which will help with its maintenance. What you guys think? I was wondering if we could use some code style standard, like Google's ( http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml), for example. This should help with the code readability, I guess. I don't know if we have some standard now, though. Best regards, Ricardo 2012/4/1 flooding Controlled <flo...@gm...> > Hi Arjan: > It sounds very interesting that you are now doing some work on the > development of the GUI. Though I think the commandline is enough for users, > I really want to try your GUI. > For additionally , which language do you use to write the GUI ? > > Yours. > Flooding. > > 在 2012年4月1日 下午3:34，Craig Peacock <cr...@be...>写道： > > >> Arjan, >> >> Now I understand the intention, I think like your structure with the >> library. You have a libsrc directory containing the library, and a src >> folder containing the command line tool. At a later date, we can prehaps >> add a GUI folder and maybe rename the src folder to something like cmdline. >> >> Considering you have invested some time into rewriting the userspace >> tools (/usbip/obsolete/linux/trunk/src/), I think I would rather use this >> version, even though it has not been thoroughtly tested and may need some >> code re-written. >> >> Would this be your advice? >> >> How far did you get with the GUI? Would you be keen to send me your work >> in progress, offline on online? >> >> Regards, >> >> Craig >> >> >> On 1/04/2012 4:06 PM, Arjan Mels wrote: >> >> Dear Craig, Ricardo, >> >> Some clarification on the different versions etc. >> >> /usbip/obsolete/linux/trunk/src/ is indeed my latest version of the >> userspace tools for windows, however the latest version which was properly >> tested is in (/usbip <http://usbip.svn.sourceforge.net/viewvc/usbip/> >> /windows/tag <http://usbip.svn.sourceforge.net/viewvc/usbip/windows/tag/> >> /usbip_windows-0.2.0.0) . It is in such a weird location because I >> started to merge the windows version with the linux version ot be able to >> also move the windows version to the linux kernel repositry. However I did >> not finish this because of some changes to the linux version which crossed >> with my version and due to the kernel system of patching etc. I needed to >> redo quit a bit of code for which I did not find time. >> >> The separate library is indeed intended to make different UI’s possible. >> I actually started with a GUI, but did also not finish this. I think it >> would be good practice to keep a separate library for the actual >> communication, but of course leave it up to you. >> >> Best Regards, >> >> Arjan Mels >> >> >> *From:* Ricardo Gomes da Silva <ca...@gm...> >> *Sent:* Sunday, April 01, 2012 5:43 >> *To:* Craig Peacock <cr...@be...> >> *Cc:* usb...@li... >> *Subject:* Re: [usbip-devel] Protocol for submitting patches / SVN access >> >> Craig, >> >> Yes, I definitely agree with you - we should take a look at the >> repository first, then patch the code. >> >> I also agree with the folder structure you suggested. It's perfectly >> clear and easy to understand. The rest of the code could be zipped and >> moved somewhere (or maybe kept in the repository, don't know) to help with >> the cleaning process. >> >> About the userspace code, I think it's the one located on >> /usbip/obsolete/linux/trunk/src/ too. The library adds no feature for the >> windows port, except that the lib can be used in another project (or >> another user interface, probably a GUI). I think that was created to allow >> a common library between windows and linux versions, but since the linux >> one is inside the kernel's repository it would be harder to keep it updated >> (I guess). I agree on merging the library into the same project. >> >> If in the future we decide to separate the library from the userspace >> application, it should be easy - the userspace shouldn't do anything * >> that* complicated. Everything, including usbip's device communication, >> should be done inside the library, not in the userspace code. I don't know >> if this is the current way, though. >> >> Regarding the driver's code, I think that both trunk and 0.2.0.0 versions >> should do the job. I just compared them here (using WinMerge) and they're >> pretty much the same thing, except some local changes I made for testing. >> >> >> Best regards, >> >> Ricardo >> >> >> PS: we can also open an IRC channel for the USB/IP project on freenode >> for offering user support and improve developers' communication. >> >> On Sun, Apr 1, 2012 at 12:12 AM, Craig Peacock <cr...@be...>wrote: >> >>> >>> Ricardo, >>> >>> I think you are on the right track. I get a lot of blue screens too. >>> >>> Personally, I would like to look at the repository first. I believe we >>> are all using the same driver code minus a few patches, but the same can't >>> be said for the userspace. My thoughts would be, if we can organise the >>> repository and decide on the base source for the usercode, then we all have >>> a common foundation to move forward on, submit patches and study/document. >>> It will be easier to start fixing some of the bugs, if we only have one >>> userspace app. >>> >>> I would be thinking of a structure like : >>> >>> usbip/windows/trunk/driver >>> usbip/windows/trunk/userspace >>> >>> so you can just check out the windows trunk and get both the current >>> driver and current userspace code, but they are physically seperated. >>> >>> The question is, should the userspace code be populated with what I >>> understand is the latest source - usbip/obsolete/linux/trunk/src/ or >>> something different? I beleive this source has a library - usbip_common. >>> The source is there, but I'm not sure if we need a library. I think we >>> should just move it, and we can always massage it later. My priority would >>> be to get everyone on the same page (source tree). >>> >>> From there, we can fix the version_mismatch problem and have at least >>> functional code. >>> >>> Regards, >>> >>> Craig >>> >>> >>> On 1/04/2012 11:23 AM, Ricardo Gomes da Silva wrote: >>> >>> Craig, >>> >>> As you requested, I've attached my patches. Actually, I guess that only >>> the daemon_tools_conflict.patch and version_mismatch.patch are mine. The >>> string_descriptors.patch was sent to the list by Tim Edmonds some time ago >>> (credits to him). >>> >>> I'd like to help fixing the Windows port. I also get some BSODs here and >>> there, so I decided to not use USB/IP in my "home" environment (where I >>> need something stable to work with, at least). >>> >>> Ironically, my Debian 6 (stable) server crashes when I'm running the >>> USB/IP server (no idea why, though), so I left that alone for a while. But, >>> as always, I can use some VMs (both for server and client) for hacking the >>> drivers and make them work properly. I used to work on a XP virtual >>> machine, and probably will continue using it (and maybe a Windows 7 VM >>> later). >>> >>> Ah, and if you kill the usbipd, Windows might get a BSOD right at the >>> same time - socket closing should be fixed! ;) >>> >>> I think that in the first moment we should study how the userspace code >>> and drivers work for fixing the most classic and possible bugs: pretty much >>> anything related with network problems. We just cannot afford the >>> possibility of having a BSOD just because we got a corrupted packet. Also >>> we must make it easier for new users: errors should give them good >>> information, not just some error codes. Or at least they could give us >>> enough information for helping the users in the troubleshooting process. >>> >>> Finally, we should reorganize the repository. Give some good folder >>> names, move everything to the correct places and make it clear. New >>> developers should be able to get a copy of the code and easily spot what's >>> driver code, what's userspace code and what's *really* obsolete. >>> >>> >>> That's all. Best regards, >>> >>> Ricardo >>> >>> >>> >>> >> ------------------------------ >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> >> ------------------------------ >> _______________________________________________ >> usbip-devel mailing list >> usb...@li... >> https://lists.sourceforge.net/lists/listinfo/usbip-devel >> >> >> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> usbip-devel mailing list >> usb...@li... >> https://lists.sourceforge.net/lists/listinfo/usbip-devel >> >> > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > usbip-devel mailing list > usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbip-devel > > |
|
From: flooding C. <flo...@gm...> - 2012-04-01 07:49:38
|
Hi Arjan: It sounds very interesting that you are now doing some work on the development of the GUI. Though I think the commandline is enough for users, I really want to try your GUI. For additionally , which language do you use to write the GUI ? Yours. Flooding. 在 2012年4月1日 下午3:34，Craig Peacock <cr...@be...>写道： > > Arjan, > > Now I understand the intention, I think like your structure with the > library. You have a libsrc directory containing the library, and a src > folder containing the command line tool. At a later date, we can prehaps > add a GUI folder and maybe rename the src folder to something like cmdline. > > Considering you have invested some time into rewriting the userspace tools > (/usbip/obsolete/linux/trunk/src/), I think I would rather use this > version, even though it has not been thoroughtly tested and may need some > code re-written. > > Would this be your advice? > > How far did you get with the GUI? Would you be keen to send me your work > in progress, offline on online? > > Regards, > > Craig > > > On 1/04/2012 4:06 PM, Arjan Mels wrote: > > Dear Craig, Ricardo, > > Some clarification on the different versions etc. > > /usbip/obsolete/linux/trunk/src/ is indeed my latest version of the > userspace tools for windows, however the latest version which was properly > tested is in (/usbip <http://usbip.svn.sourceforge.net/viewvc/usbip/> > /windows/tag <http://usbip.svn.sourceforge.net/viewvc/usbip/windows/tag/>/usbip_windows-0.2.0.0) > . It is in such a weird location because I started to merge the windows > version with the linux version ot be able to also move the windows version > to the linux kernel repositry. However I did not finish this because of > some changes to the linux version which crossed with my version and due to > the kernel system of patching etc. I needed to redo quit a bit of code for > which I did not find time. > > The separate library is indeed intended to make different UI’s possible. I > actually started with a GUI, but did also not finish this. I think it would > be good practice to keep a separate library for the actual communication, > but of course leave it up to you. > > Best Regards, > > Arjan Mels > > > *From:* Ricardo Gomes da Silva <ca...@gm...> > *Sent:* Sunday, April 01, 2012 5:43 > *To:* Craig Peacock <cr...@be...> > *Cc:* usb...@li... > *Subject:* Re: [usbip-devel] Protocol for submitting patches / SVN access > > Craig, > > Yes, I definitely agree with you - we should take a look at the repository > first, then patch the code. > > I also agree with the folder structure you suggested. It's perfectly clear > and easy to understand. The rest of the code could be zipped and moved > somewhere (or maybe kept in the repository, don't know) to help with the > cleaning process. > > About the userspace code, I think it's the one located on > /usbip/obsolete/linux/trunk/src/ too. The library adds no feature for the > windows port, except that the lib can be used in another project (or > another user interface, probably a GUI). I think that was created to allow > a common library between windows and linux versions, but since the linux > one is inside the kernel's repository it would be harder to keep it updated > (I guess). I agree on merging the library into the same project. > > If in the future we decide to separate the library from the userspace > application, it should be easy - the userspace shouldn't do anything *that > * complicated. Everything, including usbip's device communication, should > be done inside the library, not in the userspace code. I don't know if this > is the current way, though. > > Regarding the driver's code, I think that both trunk and 0.2.0.0 versions > should do the job. I just compared them here (using WinMerge) and they're > pretty much the same thing, except some local changes I made for testing. > > > Best regards, > > Ricardo > > > PS: we can also open an IRC channel for the USB/IP project on freenode for > offering user support and improve developers' communication. > > On Sun, Apr 1, 2012 at 12:12 AM, Craig Peacock <cr...@be...>wrote: > >> >> Ricardo, >> >> I think you are on the right track. I get a lot of blue screens too. >> >> Personally, I would like to look at the repository first. I believe we >> are all using the same driver code minus a few patches, but the same can't >> be said for the userspace. My thoughts would be, if we can organise the >> repository and decide on the base source for the usercode, then we all have >> a common foundation to move forward on, submit patches and study/document. >> It will be easier to start fixing some of the bugs, if we only have one >> userspace app. >> >> I would be thinking of a structure like : >> >> usbip/windows/trunk/driver >> usbip/windows/trunk/userspace >> >> so you can just check out the windows trunk and get both the current >> driver and current userspace code, but they are physically seperated. >> >> The question is, should the userspace code be populated with what I >> understand is the latest source - usbip/obsolete/linux/trunk/src/ or >> something different? I beleive this source has a library - usbip_common. >> The source is there, but I'm not sure if we need a library. I think we >> should just move it, and we can always massage it later. My priority would >> be to get everyone on the same page (source tree). >> >> From there, we can fix the version_mismatch problem and have at least >> functional code. >> >> Regards, >> >> Craig >> >> >> On 1/04/2012 11:23 AM, Ricardo Gomes da Silva wrote: >> >> Craig, >> >> As you requested, I've attached my patches. Actually, I guess that only >> the daemon_tools_conflict.patch and version_mismatch.patch are mine. The >> string_descriptors.patch was sent to the list by Tim Edmonds some time ago >> (credits to him). >> >> I'd like to help fixing the Windows port. I also get some BSODs here and >> there, so I decided to not use USB/IP in my "home" environment (where I >> need something stable to work with, at least). >> >> Ironically, my Debian 6 (stable) server crashes when I'm running the >> USB/IP server (no idea why, though), so I left that alone for a while. But, >> as always, I can use some VMs (both for server and client) for hacking the >> drivers and make them work properly. I used to work on a XP virtual >> machine, and probably will continue using it (and maybe a Windows 7 VM >> later). >> >> Ah, and if you kill the usbipd, Windows might get a BSOD right at the >> same time - socket closing should be fixed! ;) >> >> I think that in the first moment we should study how the userspace code >> and drivers work for fixing the most classic and possible bugs: pretty much >> anything related with network problems. We just cannot afford the >> possibility of having a BSOD just because we got a corrupted packet. Also >> we must make it easier for new users: errors should give them good >> information, not just some error codes. Or at least they could give us >> enough information for helping the users in the troubleshooting process. >> >> Finally, we should reorganize the repository. Give some good folder >> names, move everything to the correct places and make it clear. New >> developers should be able to get a copy of the code and easily spot what's >> driver code, what's userspace code and what's *really* obsolete. >> >> >> That's all. Best regards, >> >> Ricardo >> >> >> >> > ------------------------------ > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > > ------------------------------ > _______________________________________________ > usbip-devel mailing list > usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbip-devel > > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > usbip-devel mailing list > usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbip-devel > > |
|
From: Craig P. <cr...@be...> - 2012-04-01 07:34:15
|
Arjan, Now I understand the intention, I think like your structure with the library. You have a libsrc directory containing the library, and a src folder containing the command line tool. At a later date, we can prehaps add a GUI folder and maybe rename the src folder to something like cmdline. Considering you have invested some time into rewriting the userspace tools (/usbip/obsolete/linux/trunk/src/), I think I would rather use this version, even though it has not been thoroughtly tested and may need some code re-written. Would this be your advice? How far did you get with the GUI? Would you be keen to send me your work in progress, offline on online? Regards, Craig On 1/04/2012 4:06 PM, Arjan Mels wrote: > Dear Craig, Ricardo, > Some clarification on the different versions etc. > /usbip/obsolete/linux/trunk/src/ is indeed my latest version of the > userspace tools for windows, however the latest version which was > properly tested is in (/usbip > <http://usbip.svn.sourceforge.net/viewvc/usbip/>/windows/tag > <http://usbip.svn.sourceforge.net/viewvc/usbip/windows/tag/>/usbip_windows-0.2.0.0) > . It is in such a weird location because I started to merge the > windows version with the linux version ot be able to also move the > windows version to the linux kernel repositry. However I did not > finish this because of some changes to the linux version which crossed > with my version and due to the kernel system of patching etc. I needed > to redo quit a bit of code for which I did not find time. > The separate library is indeed intended to make different UI’s > possible. I actually started with a GUI, but did also not finish this. > I think it would be good practice to keep a separate library for the > actual communication, but of course leave it up to you. > Best Regards, > Arjan Mels > *From:* Ricardo Gomes da Silva <mailto:ca...@gm...> > *Sent:* Sunday, April 01, 2012 5:43 > *To:* Craig Peacock <mailto:cr...@be...> > *Cc:* usb...@li... > <mailto:usb...@li...> > *Subject:* Re: [usbip-devel] Protocol for submitting patches / SVN access > Craig, > > Yes, I definitely agree with you - we should take a look at the > repository first, then patch the code. > > I also agree with the folder structure you suggested. It's perfectly > clear and easy to understand. The rest of the code could be zipped and > moved somewhere (or maybe kept in the repository, don't know) to help > with the cleaning process. > > About the userspace code, I think it's the one located on > /usbip/obsolete/linux/trunk/src/ too. The library adds no feature for > the windows port, except that the lib can be used in another project > (or another user interface, probably a GUI). I think that was created > to allow a common library between windows and linux versions, but > since the linux one is inside the kernel's repository it would be > harder to keep it updated (I guess). I agree on merging the library > into the same project. > > If in the future we decide to separate the library from the userspace > application, it should be easy - the userspace shouldn't do anything > /that/ complicated. Everything, including usbip's device > communication, should be done inside the library, not in the userspace > code. I don't know if this is the current way, though. > > Regarding the driver's code, I think that both trunk and 0.2.0.0 > versions should do the job. I just compared them here (using WinMerge) > and they're pretty much the same thing, except some local changes I > made for testing. > > > Best regards, > > Ricardo > > > PS: we can also open an IRC channel for the USB/IP project on freenode > for offering user support and improve developers' communication. > > On Sun, Apr 1, 2012 at 12:12 AM, Craig Peacock <cr...@be... > <mailto:cr...@be...>> wrote: > > > Ricardo, > > I think you are on the right track. I get a lot of blue screens too. > > Personally, I would like to look at the repository first. I > believe we are all using the same driver code minus a few patches, > but the same can't be said for the userspace. My thoughts would > be, if we can organise the repository and decide on the base > source for the usercode, then we all have a common foundation to > move forward on, submit patches and study/document. It will be > easier to start fixing some of the bugs, if we only have one > userspace app. > > I would be thinking of a structure like : > > usbip/windows/trunk/driver > usbip/windows/trunk/userspace > > so you can just check out the windows trunk and get both the > current driver and current userspace code, but they are physically > seperated. > > The question is, should the userspace code be populated with what > I understand is the latest source - > usbip/obsolete/linux/trunk/src/ or something different? I beleive > this source has a library - usbip_common. The source is there, but > I'm not sure if we need a library. I think we should just move it, > and we can always massage it later. My priority would be to get > everyone on the same page (source tree). > > From there, we can fix the version_mismatch problem and have at > least functional code. > > Regards, > > Craig > > > On 1/04/2012 11:23 AM, Ricardo Gomes da Silva wrote: >> Craig, >> >> As you requested, I've attached my patches. Actually, I guess >> that only the daemon_tools_conflict.patch and >> version_mismatch.patch are mine. The string_descriptors.patch was >> sent to the list by Tim Edmonds some time ago (credits to him). >> >> I'd like to help fixing the Windows port. I also get some BSODs >> here and there, so I decided to not use USB/IP in my "home" >> environment (where I need something stable to work with, at least). >> >> Ironically, my Debian 6 (stable) server crashes when I'm running >> the USB/IP server (no idea why, though), so I left that alone for >> a while. But, as always, I can use some VMs (both for server and >> client) for hacking the drivers and make them work properly. I >> used to work on a XP virtual machine, and probably will continue >> using it (and maybe a Windows 7 VM later). >> >> Ah, and if you kill the usbipd, Windows might get a BSOD right at >> the same time - socket closing should be fixed! ;) >> >> I think that in the first moment we should study how the >> userspace code and drivers work for fixing the most classic and >> possible bugs: pretty much anything related with network >> problems. We just cannot afford the possibility of having a BSOD >> just because we got a corrupted packet. Also we must make it >> easier for new users: errors should give them good information, >> not just some error codes. Or at least they could give us enough >> information for helping the users in the troubleshooting process. >> >> Finally, we should reorganize the repository. Give some good >> folder names, move everything to the correct places and make it >> clear. New developers should be able to get a copy of the code >> and easily spot what's driver code, what's userspace code and >> what's /really/ obsolete. >> >> >> That's all. Best regards, >> >> Ricardo > > > > ------------------------------------------------------------------------ > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > > ------------------------------------------------------------------------ > _______________________________________________ > usbip-devel mailing list > usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbip-devel |
|
From: Arjan M. <arj...@gm...> - 2012-04-01 06:35:22
|
Dear Craig, Ricardo,
Some clarification on the different versions etc.
/usbip/obsolete/linux/trunk/src/ is indeed my latest version of the userspace tools for windows, however the latest version which was properly tested is in (/usbip/windows/tag/usbip_windows-0.2.0.0) . It is in such a weird location because I started to merge the windows version with the linux version ot be able to also move the windows version to the linux kernel repositry. However I did not finish this because of some changes to the linux version which crossed with my version and due to the kernel system of patching etc. I needed to redo quit a bit of code for which I did not find time.
The separate library is indeed intended to make different UI’s possible. I actually started with a GUI, but did also not finish this. I think it would be good practice to keep a separate library for the actual communication, but of course leave it up to you.
Best Regards,
Arjan Mels
From: Ricardo Gomes da Silva
Sent: Sunday, April 01, 2012 5:43
To: Craig Peacock
Cc: usb...@li...
Subject: Re: [usbip-devel] Protocol for submitting patches / SVN access
Craig,
Yes, I definitely agree with you - we should take a look at the repository first, then patch the code.
I also agree with the folder structure you suggested. It's perfectly clear and easy to understand. The rest of the code could be zipped and moved somewhere (or maybe kept in the repository, don't know) to help with the cleaning process.
About the userspace code, I think it's the one located on /usbip/obsolete/linux/trunk/src/ too. The library adds no feature for the windows port, except that the lib can be used in another project (or another user interface, probably a GUI). I think that was created to allow a common library between windows and linux versions, but since the linux one is inside the kernel's repository it would be harder to keep it updated (I guess). I agree on merging the library into the same project.
If in the future we decide to separate the library from the userspace application, it should be easy - the userspace shouldn't do anything that complicated. Everything, including usbip's device communication, should be done inside the library, not in the userspace code. I don't know if this is the current way, though.
Regarding the driver's code, I think that both trunk and 0.2.0.0 versions should do the job. I just compared them here (using WinMerge) and they're pretty much the same thing, except some local changes I made for testing.
Best regards,
Ricardo
PS: we can also open an IRC channel for the USB/IP project on freenode for offering user support and improve developers' communication.
On Sun, Apr 1, 2012 at 12:12 AM, Craig Peacock <cr...@be...> wrote:
Ricardo,
I think you are on the right track. I get a lot of blue screens too.
Personally, I would like to look at the repository first. I believe we are all using the same driver code minus a few patches, but the same can't be said for the userspace. My thoughts would be, if we can organise the repository and decide on the base source for the usercode, then we all have a common foundation to move forward on, submit patches and study/document. It will be easier to start fixing some of the bugs, if we only have one userspace app.
I would be thinking of a structure like :
usbip/windows/trunk/driver
usbip/windows/trunk/userspace
so you can just check out the windows trunk and get both the current driver and current userspace code, but they are physically seperated.
The question is, should the userspace code be populated with what I understand is the latest source - usbip/obsolete/linux/trunk/src/ or something different? I beleive this source has a library - usbip_common. The source is there, but I'm not sure if we need a library. I think we should just move it, and we can always massage it later. My priority would be to get everyone on the same page (source tree).
From there, we can fix the version_mismatch problem and have at least functional code.
Regards,
Craig
On 1/04/2012 11:23 AM, Ricardo Gomes da Silva wrote:
Craig,
As you requested, I've attached my patches. Actually, I guess that only the daemon_tools_conflict.patch and version_mismatch.patch are mine. The string_descriptors.patch was sent to the list by Tim Edmonds some time ago (credits to him).
I'd like to help fixing the Windows port. I also get some BSODs here and there, so I decided to not use USB/IP in my "home" environment (where I need something stable to work with, at least).
Ironically, my Debian 6 (stable) server crashes when I'm running the USB/IP server (no idea why, though), so I left that alone for a while. But, as always, I can use some VMs (both for server and client) for hacking the drivers and make them work properly. I used to work on a XP virtual machine, and probably will continue using it (and maybe a Windows 7 VM later).
Ah, and if you kill the usbipd, Windows might get a BSOD right at the same time - socket closing should be fixed! ;)
I think that in the first moment we should study how the userspace code and drivers work for fixing the most classic and possible bugs: pretty much anything related with network problems. We just cannot afford the possibility of having a BSOD just because we got a corrupted packet. Also we must make it easier for new users: errors should give them good information, not just some error codes. Or at least they could give us enough information for helping the users in the troubleshooting process.
Finally, we should reorganize the repository. Give some good folder names, move everything to the correct places and make it clear. New developers should be able to get a copy of the code and easily spot what's driver code, what's userspace code and what's really obsolete.
That's all. Best regards,
Ricardo
--------------------------------------------------------------------------------
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
--------------------------------------------------------------------------------
_______________________________________________
usbip-devel mailing list
usb...@li...
https://lists.sourceforge.net/lists/listinfo/usbip-devel
|
|
From: Ricardo G. da S. <ca...@gm...> - 2012-04-01 03:43:42
|
Craig, Yes, I definitely agree with you - we should take a look at the repository first, then patch the code. I also agree with the folder structure you suggested. It's perfectly clear and easy to understand. The rest of the code could be zipped and moved somewhere (or maybe kept in the repository, don't know) to help with the cleaning process. About the userspace code, I think it's the one located on /usbip/obsolete/linux/trunk/src/ too. The library adds no feature for the windows port, except that the lib can be used in another project (or another user interface, probably a GUI). I think that was created to allow a common library between windows and linux versions, but since the linux one is inside the kernel's repository it would be harder to keep it updated (I guess). I agree on merging the library into the same project. If in the future we decide to separate the library from the userspace application, it should be easy - the userspace shouldn't do anything *that*complicated. Everything, including usbip's device communication, should be done inside the library, not in the userspace code. I don't know if this is the current way, though. Regarding the driver's code, I think that both trunk and 0.2.0.0 versions should do the job. I just compared them here (using WinMerge) and they're pretty much the same thing, except some local changes I made for testing. Best regards, Ricardo PS: we can also open an IRC channel for the USB/IP project on freenode for offering user support and improve developers' communication. On Sun, Apr 1, 2012 at 12:12 AM, Craig Peacock <cr...@be...>wrote: > > Ricardo, > > I think you are on the right track. I get a lot of blue screens too. > > Personally, I would like to look at the repository first. I believe we are > all using the same driver code minus a few patches, but the same can't be > said for the userspace. My thoughts would be, if we can organise the > repository and decide on the base source for the usercode, then we all have > a common foundation to move forward on, submit patches and study/document. > It will be easier to start fixing some of the bugs, if we only have one > userspace app. > > I would be thinking of a structure like : > > usbip/windows/trunk/driver > usbip/windows/trunk/userspace > > so you can just check out the windows trunk and get both the current > driver and current userspace code, but they are physically seperated. > > The question is, should the userspace code be populated with what I > understand is the latest source - usbip/obsolete/linux/trunk/src/ or > something different? I beleive this source has a library - usbip_common. > The source is there, but I'm not sure if we need a library. I think we > should just move it, and we can always massage it later. My priority would > be to get everyone on the same page (source tree). > > From there, we can fix the version_mismatch problem and have at least > functional code. > > Regards, > > Craig > > > On 1/04/2012 11:23 AM, Ricardo Gomes da Silva wrote: > > Craig, > > As you requested, I've attached my patches. Actually, I guess that only > the daemon_tools_conflict.patch and version_mismatch.patch are mine. The > string_descriptors.patch was sent to the list by Tim Edmonds some time ago > (credits to him). > > I'd like to help fixing the Windows port. I also get some BSODs here and > there, so I decided to not use USB/IP in my "home" environment (where I > need something stable to work with, at least). > > Ironically, my Debian 6 (stable) server crashes when I'm running the > USB/IP server (no idea why, though), so I left that alone for a while. But, > as always, I can use some VMs (both for server and client) for hacking the > drivers and make them work properly. I used to work on a XP virtual > machine, and probably will continue using it (and maybe a Windows 7 VM > later). > > Ah, and if you kill the usbipd, Windows might get a BSOD right at the same > time - socket closing should be fixed! ;) > > I think that in the first moment we should study how the userspace code > and drivers work for fixing the most classic and possible bugs: pretty much > anything related with network problems. We just cannot afford the > possibility of having a BSOD just because we got a corrupted packet. Also > we must make it easier for new users: errors should give them good > information, not just some error codes. Or at least they could give us > enough information for helping the users in the troubleshooting process. > > Finally, we should reorganize the repository. Give some good folder names, > move everything to the correct places and make it clear. New developers > should be able to get a copy of the code and easily spot what's driver > code, what's userspace code and what's *really* obsolete. > > > That's all. Best regards, > > Ricardo > > > > |
|
From: Craig P. <cr...@be...> - 2012-04-01 03:11:52
|
Ricardo, I think you are on the right track. I get a lot of blue screens too. Personally, I would like to look at the repository first. I believe we are all using the same driver code minus a few patches, but the same can't be said for the userspace. My thoughts would be, if we can organise the repository and decide on the base source for the usercode, then we all have a common foundation to move forward on, submit patches and study/document. It will be easier to start fixing some of the bugs, if we only have one userspace app. I would be thinking of a structure like : usbip/windows/trunk/driver usbip/windows/trunk/userspace so you can just check out the windows trunk and get both the current driver and current userspace code, but they are physically seperated. The question is, should the userspace code be populated with what I understand is the latest source - usbip/obsolete/linux/trunk/src/ or something different? I beleive this source has a library - usbip_common. The source is there, but I'm not sure if we need a library. I think we should just move it, and we can always massage it later. My priority would be to get everyone on the same page (source tree). From there, we can fix the version_mismatch problem and have at least functional code. Regards, Craig On 1/04/2012 11:23 AM, Ricardo Gomes da Silva wrote: > Craig, > > As you requested, I've attached my patches. Actually, I guess that > only the daemon_tools_conflict.patch and version_mismatch.patch are > mine. The string_descriptors.patch was sent to the list by Tim Edmonds > some time ago (credits to him). > > I'd like to help fixing the Windows port. I also get some BSODs here > and there, so I decided to not use USB/IP in my "home" environment > (where I need something stable to work with, at least). > > Ironically, my Debian 6 (stable) server crashes when I'm running the > USB/IP server (no idea why, though), so I left that alone for a while. > But, as always, I can use some VMs (both for server and client) for > hacking the drivers and make them work properly. I used to work on a > XP virtual machine, and probably will continue using it (and maybe a > Windows 7 VM later). > > Ah, and if you kill the usbipd, Windows might get a BSOD right at the > same time - socket closing should be fixed! ;) > > I think that in the first moment we should study how the userspace > code and drivers work for fixing the most classic and possible bugs: > pretty much anything related with network problems. We just cannot > afford the possibility of having a BSOD just because we got a > corrupted packet. Also we must make it easier for new users: errors > should give them good information, not just some error codes. Or at > least they could give us enough information for helping the users in > the troubleshooting process. > > Finally, we should reorganize the repository. Give some good folder > names, move everything to the correct places and make it clear. New > developers should be able to get a copy of the code and easily spot > what's driver code, what's userspace code and what's /really/ obsolete. > > > That's all. Best regards, > > Ricardo |
|
From: flooding C. <flo...@gm...> - 2012-03-31 07:51:51
|
Hi Craig:
Have you compiled the windows driver for linux kernel(3.1.0 or later),
could mail me your project ? My work is now focusing on it,and I want to
try it myself.
Thanks a lot.
在 2012年3月31日 下午2:55，Craig Peacock <cr...@be...>写道：
>
> Ricardo,
>
> I've just asked for subversion access. If you can please upload your
> patches again, we might try for a coordinated effort in the next couple of
> weeks to get the windows drivers up to date.
>
> Regards,
>
> Craig
>
>
> On 31/03/2012 4:21 AM, Ricardo Gomes da Silva wrote:
>
> Just to remember you guys that other people (including myself) had
> submitted patches some time ago on this list. Some of the oldest usbip
> windows client problems, like conflicts with the Daemon Tools driver, had
> been fixed. USB/IP protocol version and device name buffer size had also
> been changed.
>
> I have some patches at home (somewhere...) that you guys may be interested
> into. I think I've sent them, but I can upload again if you want.
>
>
> Best regards,
>
> Ricardo
>
> On Fri, Mar 30, 2012 at 2:23 PM, Arjan Mels <arj...@gm...> wrote:
>
>> Dear Craig,
>>
>> The last changes were done by me. Unfortunately I have had very limited
>> time to work on this project since then.
>>
>> If you let me know your user name on sourceforge, I can add you as a
>> developer and you can edit the files yourself in SVN. Once you think it is
>> a stable/robust version we can ask to get the binary signed, so it will run
>> on x64 versions properly.
>>
>> Best Regards,
>>
>> Arjan
>>
>>
>> *From:* Craig Peacock <cr...@be...>
>> *Sent:* Friday, March 30, 2012 3:53
>> *To:* usb...@li...
>> *Subject:* [usbip-devel] Protocol for submitting patches / SVN access
>>
>>
>> usbip-devel list,
>>
>> I make the observation that the subversion repository for the Windows
>> client driver hasn't been updated for 9 months. I understand the kernel and
>> linux userland utilities are now in the staging directory of the kernel and
>> there is work happening on refining in. I also make the observation of a
>> couple of BSOD with the Windows driver and protocol version problems with
>> the stock 2.0.0.0 driver.
>>
>> I would like to assist with refining the Windows client driver. What is
>> the protocol for doing this? If we submit patches to this list (Like Tim
>> Edmonds on the 29/3) will a developer approve and fold these patches into
>> SVN?
>>
>> I contacted Dan Tesone last week and he has given me copies of some of
>> this modifications. I've had a little hack myself, so it would seem there
>> are multiple individuals working on this, but no coordinated effort.
>>
>> Regards,
>>
>> Craig
>>
>>
>>
>> ------------------------------
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>>
>> ------------------------------
>> _______________________________________________
>> usbip-devel mailing list
>> usb...@li...
>> https://lists.sourceforge.net/lists/listinfo/usbip-devel
>>
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> usbip-devel mailing list
>> usb...@li...
>> https://lists.sourceforge.net/lists/listinfo/usbip-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
>
>
>
> _______________________________________________
> usbip-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/usbip-devel
>
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> usbip-devel mailing list
> usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbip-devel
>
>
|
|
From: Craig P. <cr...@be...> - 2012-03-31 06:54:55
|
Ricardo, I've just asked for subversion access. If you can please upload your patches again, we might try for a coordinated effort in the next couple of weeks to get the windows drivers up to date. Regards, Craig On 31/03/2012 4:21 AM, Ricardo Gomes da Silva wrote: > Just to remember you guys that other people (including myself) had > submitted patches some time ago on this list. Some of the oldest usbip > windows client problems, like conflicts with the Daemon Tools driver, > had been fixed. USB/IP protocol version and device name buffer size > had also been changed. > > I have some patches at home (somewhere...) that you guys may be > interested into. I think I've sent them, but I can upload again if you > want. > > > Best regards, > > Ricardo > > On Fri, Mar 30, 2012 at 2:23 PM, Arjan Mels <arj...@gm... > <mailto:arj...@gm...>> wrote: > > Dear Craig, > The last changes were done by me. Unfortunately I have had very > limited time to work on this project since then. > If you let me know your user name on sourceforge, I can add you as > a developer and you can edit the files yourself in SVN. Once you > think it is a stable/robust version we can ask to get the binary > signed, so it will run on x64 versions properly. > Best Regards, > > Arjan > *From:* Craig Peacock <mailto:cr...@be...> > *Sent:* Friday, March 30, 2012 3:53 > *To:* usb...@li... > <mailto:usb...@li...> > *Subject:* [usbip-devel] Protocol for submitting patches / SVN access > > usbip-devel list, > > I make the observation that the subversion repository for the > Windows client driver hasn't been updated for 9 months. I > understand the kernel and linux userland utilities are now in the > staging directory of the kernel and there is work happening on > refining in. I also make the observation of a couple of BSOD with > the Windows driver and protocol version problems with the stock > 2.0.0.0 driver. > > I would like to assist with refining the Windows client driver. > What is the protocol for doing this? If we submit patches to this > list (Like Tim Edmonds on the 29/3) will a developer approve and > fold these patches into SVN? > > I contacted Dan Tesone last week and he has given me copies of > some of this modifications. I've had a little hack myself, so it > would seem there are multiple individuals working on this, but no > coordinated effort. > > Regards, > > Craig > > > > ------------------------------------------------------------------------ > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > > ------------------------------------------------------------------------ > _______________________________________________ > usbip-devel mailing list > usb...@li... > <mailto:usb...@li...> > https://lists.sourceforge.net/lists/listinfo/usbip-devel > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > usbip-devel mailing list > usb...@li... > <mailto:usb...@li...> > https://lists.sourceforge.net/lists/listinfo/usbip-devel > > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > > > _______________________________________________ > usbip-devel mailing list > usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbip-devel |
|
From: Ricardo G. da S. <ca...@gm...> - 2012-03-30 17:51:45
|
Just to remember you guys that other people (including myself) had submitted patches some time ago on this list. Some of the oldest usbip windows client problems, like conflicts with the Daemon Tools driver, had been fixed. USB/IP protocol version and device name buffer size had also been changed. I have some patches at home (somewhere...) that you guys may be interested into. I think I've sent them, but I can upload again if you want. Best regards, Ricardo On Fri, Mar 30, 2012 at 2:23 PM, Arjan Mels <arj...@gm...> wrote: > Dear Craig, > > The last changes were done by me. Unfortunately I have had very limited > time to work on this project since then. > > If you let me know your user name on sourceforge, I can add you as a > developer and you can edit the files yourself in SVN. Once you think it is > a stable/robust version we can ask to get the binary signed, so it will run > on x64 versions properly. > > Best Regards, > > Arjan > > > *From:* Craig Peacock <cr...@be...> > *Sent:* Friday, March 30, 2012 3:53 > *To:* usb...@li... > *Subject:* [usbip-devel] Protocol for submitting patches / SVN access > > **** > usbip-devel list, > > I make the observation that the subversion repository for the Windows > client driver hasn't been updated for 9 months. I understand the kernel and > linux userland utilities are now in the staging directory of the kernel and > there is work happening on refining in. I also make the observation of a > couple of BSOD with the Windows driver and protocol version problems with > the stock 2.0.0.0 driver. > > I would like to assist with refining the Windows client driver. What is > the protocol for doing this? If we submit patches to this list (Like Tim > Edmonds on the 29/3) will a developer approve and fold these patches into > SVN? > > I contacted Dan Tesone last week and he has given me copies of some of > this modifications. I've had a little hack myself, so it would seem there > are multiple individuals working on this, but no coordinated effort. > > Regards, > > Craig > > > > ------------------------------ > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > > ------------------------------ > _______________________________________________ > usbip-devel mailing list > usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbip-devel > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > usbip-devel mailing list > usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbip-devel > > |
|
From: Arjan M. <arj...@gm...> - 2012-03-30 17:22:40
|
Dear Craig, The last changes were done by me. Unfortunately I have had very limited time to work on this project since then. If you let me know your user name on sourceforge, I can add you as a developer and you can edit the files yourself in SVN. Once you think it is a stable/robust version we can ask to get the binary signed, so it will run on x64 versions properly. Best Regards, Arjan From: Craig Peacock Sent: Friday, March 30, 2012 3:53 To: usb...@li... Subject: [usbip-devel] Protocol for submitting patches / SVN access usbip-devel list, I make the observation that the subversion repository for the Windows client driver hasn't been updated for 9 months. I understand the kernel and linux userland utilities are now in the staging directory of the kernel and there is work happening on refining in. I also make the observation of a couple of BSOD with the Windows driver and protocol version problems with the stock 2.0.0.0 driver. I would like to assist with refining the Windows client driver. What is the protocol for doing this? If we submit patches to this list (Like Tim Edmonds on the 29/3) will a developer approve and fold these patches into SVN? I contacted Dan Tesone last week and he has given me copies of some of this modifications. I've had a little hack myself, so it would seem there are multiple individuals working on this, but no coordinated effort. Regards, Craig -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure -------------------------------------------------------------------------------- _______________________________________________ usbip-devel mailing list usb...@li... https://lists.sourceforge.net/lists/listinfo/usbip-devel |
|
From: flooding C. <flo...@gm...> - 2012-03-30 16:53:43
|
Hi all:
I downloaded the window client project for VS2010 and recompile myself.
I modified the file usb_ip_protocol.c '#define USBIP_VERSION 0x000106'
to '#define USBIP_VERSION 0x000111' , and the usbip.exe genrated could work
well with the server side(linux kernel version 3.1.10 and 3.3).
Then I made it work with the the server side(linux kernel version
3.1.0-7.fc16.i686.PAE). And I run the command "usbip.exe -l 192.168.3.128"
, OK, it worked well as follows:
- 192.168.3.128
1-1: unknown vendor : unknown product (058f:6387)
: /sys/devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/1-1
: (Defined at Interface level) (00/00/00)
: 0 - unknown class / unknown subclass / unknown protocol
(08/06/50)
However, I run the command "usbip.exe -a 192.168.3.128 1-1", it called the
error sa follows:
usbip for windows ($Id$)
new usb device attached to usbvbus port 1
usbip err: c:\usbip_windows-0.2.0.0\usbip_vbus_ui.c: 356 (write_to_dev)
read from
sock ret 0 not equal a usbip_header
Well, could someone give me some help ? How to match the client version
with the server version?
Thanks a lot!
Yours.
Flooding.
|
|
From: Craig P. <cr...@be...> - 2012-03-30 01:52:33
|
usbip-devel list, I make the observation that the subversion repository for the Windows client driver hasn't been updated for 9 months. I understand the kernel and linux userland utilities are now in the staging directory of the kernel and there is work happening on refining in. I also make the observation of a couple of BSOD with the Windows driver and protocol version problems with the stock 2.0.0.0 driver. I would like to assist with refining the Windows client driver. What is the protocol for doing this? If we submit patches to this list (Like Tim Edmonds on the 29/3) will a developer approve and fold these patches into SVN? I contacted Dan Tesone last week and he has given me copies of some of this modifications. I've had a little hack myself, so it would seem there are multiple individuals working on this, but no coordinated effort. Regards, Craig |
|
From: Craig P. <cr...@be...> - 2012-03-30 01:40:45
|
Flooding, May I please ask that you reply back to the mailing list and not to the individual, this way you open up the floor to other people on the list responding to your question. May I also ask you keep your query to the one thread, i.e. 'can not load usbip.ko' rather than spamming the 'Windows client driver patch - cancel routine, hardware ID BSOD.' - This makes the discussion easier to follow. Regarding your problem with the client driver, I believe it's a version mismatch problem. In your windows source tree, there should be a usbip_windows_v0.2.0.0_signed\usbip_protocol.h file containing a version definition: #define USBIP_VERSION 0x000106 Change it to #define USBIP_VERSION 0x00000111, recompile and see what happens. This is just a hack I have come up with, I would be interested in what the official solution should be. Regards, Craig On 29/03/2012 11:39 PM, flooding Controlled wrote: > Hi: > I have successfully installed the server side. However, on my client > side(windows XP 3 32bit), I use the usbip_windows_v0.2.0.0_signed and > type the command in the cmd: > C:\usbip_windows_v0.2.0.0_signed>usbip.exe -l 192.168.23.131 > > the error are as follows: > > - 192.168.23.131 > usbip err: usbip_network.c: 121 (usbip_recv_op_common) recv op_common, -1 > usbip err: usbip.c: 216 (query_exported_devices) recv op_common > usbip err: usbip.c: 288 (show_exported_devices) query > > Could you give me some suggestions? Thanks a lot! > > > > 在 2012年3月29日 下午7:35，flooding Controlled <flo...@gm... > <mailto:flo...@gm...>>写 道： > > > > 在 2012年3月29日 下午7:35，flooding Controlled > <flo...@gm... <mailto:flo...@gm...>>写 道： > > Hi Craig: > Thanks a lot! I am tring it! Thanks for your help! > > > > 在 2012年3月29日 下午6:19，Craig Peacock > <cr...@be... <mailto:cr...@be...>>写 道： > > > Sorry Flooding, I think I misread what you are asking. > > I believe you are asking how to install the drivers, not > the userland utilties. > > The drivers are part of the kernel and can be found in the > kernel menu under Device Drivers -> Staging drivers -> > USB/IP support. > > I assume you already have compiled these as modules with > your 3.1 kernel? > > Regards, > > Craig > > > > On 29/03/2012 8:43 PM, Craig Peacock wrote: >> >> Flooding, >> >> To compile the userland utilities, you will have to run >> the autogen.sh script first. Then you can run configure. >> >> cd drivers/staging/usbip/userspace >> ./autogen.sh >> ./configure >> make >> make install >> >> Regards, >> >> Craig >> >> On 29/03/2012 7:55 PM, flooding Controlled wrote: >>> Hi: >>> I have followed the steps in the README file: >>> [Install] >>> 0. Generate configuration scripts. >>> $ ./autogen.sh >>> 1. Compile & install the userspace utilities. >>> $ ./configure [--with-tcp-wrappers=no] >>> [--with-usbids-dir=<dir>] >>> $ make install >>> 2. Compile & install USB/IP drivers. >>> Then I have finished the first step. And how to do the >>> second step "Compile & install USB/IP drivers". >>> >>> For I have run the command under "drivers/staging/usbip" >>> , but the Makefile in the folder has no target. >>> >>> Could tell me how to do this? Thanks a lot! >>> >>> 在 2012年3月29日 下午4:07，Craig Peacock >>> <cr...@be... <mailto:cr...@be...>> >>> 写 道： >>> >>> >>> Flooding, >>> >>> The 0.1.7 userland utilities found on sourceforge is >>> obsolete. >>> >>> Your kernel source (3.1) will include userland >>> utilities in the drivers/staging/usbip/userspace >>> folder. Please compile and give these utilities a go. >>> >>> Regards, >>> >>> Craig >>> >>> >>> >>> On 29/03/2012 6:04 PM, flooding Controlled wrote: >>>> Hi all: >>>> My linux release is Feodra 16 i686 and I have >>>> downloaded the linux kernel src with the version >>>> 3.1. Then I compiled the usbip.ko and >>>> usbip_common_mod.ko successfully by (my kernel >>>> path)/driver/stage/usbip/* . >>>> And I can load them successfully. >>>> modprobe usbip >>>> modprobe usbip_common_mod >>>> Then I installed the usbip.0.17 by src following >>>> the src/REAMME successfully. >>>> Howerver, when I run the command "usbipd", it >>>> called the error as follow: >>>> usbip err: stub_driver.c: 33 >>>> (open_sysfs_stub_driver) usbip_common_mod.ko and >>>> usbip.ko must be loaded >>>> I am puzzled by it. Coule someone give help? Thanks >>>> a lot! >>>> Yours Flooding. >>>> >>> >>> >> > > > > |
|
From: flooding C. <flo...@gm...> - 2012-03-30 01:24:42
|
Hi: I have successfully installed the server side(Feodra 16 32bit with the kernel version 3.1). However, on my client side(windows XP 3 32bit), I use the usbip_windows_v0.2.0.0_signed and type the command in the cmd: C:\usbip_windows_v0.2.0.0_signed>usbip.exe -l 192.168.23.131 the error are as follows: - 192.168.23.131 usbip err: usbip_network.c: 121 (usbip_recv_op_common) recv op_common, -1 usbip err: usbip.c: 216 (query_exported_devices) recv op_common usbip err: usbip.c: 288 (show_exported_devices) query Could you give me some suggestions? Thanks a lot! 在 2012年3月29日 下午7:26，Tim Edmonds <Tim...@di...>写道： > ** ** > > Attached patch includes two fixes to windows client driver pnp.c:**** > > ** ** > > 1/ Unset IRP cancel routine on device unplug. Detected by Driver Verifier. > **** > > ** ** > > 2/ Fix iteration over wchar hardware ID string. Fixes occasional BSOD.**** > > ** ** > > Regards,**** > > Tim**** > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > usbip-devel mailing list > usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbip-devel > > |
|
From: Craig P. <cr...@be...> - 2012-03-29 10:18:39
|
Sorry Flooding, I think I misread what you are asking. I believe you are asking how to install the drivers, not the userland utilties. The drivers are part of the kernel and can be found in the kernel menu under Device Drivers -> Staging drivers -> USB/IP support. I assume you already have compiled these as modules with your 3.1 kernel? Regards, Craig On 29/03/2012 8:43 PM, Craig Peacock wrote: > > Flooding, > > To compile the userland utilities, you will have to run the autogen.sh > script first. Then you can run configure. > > cd drivers/staging/usbip/userspace > ./autogen.sh > ./configure > make > make install > > Regards, > > Craig > > On 29/03/2012 7:55 PM, flooding Controlled wrote: >> Hi: >> I have followed the steps in the README file: >> [Install] >> 0. Generate configuration scripts. >> $ ./autogen.sh >> 1. Compile & install the userspace utilities. >> $ ./configure [--with-tcp-wrappers=no] [--with-usbids-dir=<dir>] >> $ make install >> 2. Compile & install USB/IP drivers. >> Then I have finished the first step. And how to do the second step >> "Compile & install USB/IP drivers". >> >> For I have run the command under "drivers/staging/usbip" , but the >> Makefile in the folder has no target. >> >> Could tell me how to do this? Thanks a lot! >> >> 在 2012年3月29日 下午4:07，Craig Peacock <cr...@be... >> <mailto:cr...@be...>>写 道： >> >> >> Flooding, >> >> The 0.1.7 userland utilities found on sourceforge is obsolete. >> >> Your kernel source (3.1) will include userland utilities in the >> drivers/staging/usbip/userspace folder. Please compile and give >> these utilities a go. >> >> Regards, >> >> Craig >> >> >> >> On 29/03/2012 6:04 PM, flooding Controlled wrote: >>> Hi all: >>> My linux release is Feodra 16 i686 and I have downloaded the >>> linux kernel src with the version 3.1. Then I compiled the >>> usbip.ko and usbip_common_mod.ko successfully by (my kernel >>> path)/driver/stage/usbip/* . >>> And I can load them successfully. >>> modprobe usbip >>> modprobe usbip_common_mod >>> Then I installed the usbip.0.17 by src following the src/REAMME >>> successfully. >>> Howerver, when I run the command "usbipd", it called the error >>> as follow: >>> usbip err: stub_driver.c: 33 (open_sysfs_stub_driver) >>> usbip_common_mod.ko and usbip.ko must be loaded >>> I am puzzled by it. Coule someone give help? Thanks a lot! >>> Yours Flooding. >>> >> >> > |
|
From: Craig P. <cr...@be...> - 2012-03-29 10:13:18
|
Flooding, To compile the userland utilities, you will have to run the autogen.sh script first. Then you can run configure. cd drivers/staging/usbip/userspace ./autogen.sh ./configure make make install Regards, Craig On 29/03/2012 7:55 PM, flooding Controlled wrote: > Hi: > I have followed the steps in the README file: > [Install] > 0. Generate configuration scripts. > $ ./autogen.sh > 1. Compile & install the userspace utilities. > $ ./configure [--with-tcp-wrappers=no] [--with-usbids-dir=<dir>] > $ make install > 2. Compile & install USB/IP drivers. > Then I have finished the first step. And how to do the second step > "Compile & install USB/IP drivers". > > For I have run the command under "drivers/staging/usbip" , but the > Makefile in the folder has no target. > > Could tell me how to do this? Thanks a lot! > > 在 2012年3月29日 下午4:07，Craig Peacock <cr...@be... > <mailto:cr...@be...>>写 道： > > > Flooding, > > The 0.1.7 userland utilities found on sourceforge is obsolete. > > Your kernel source (3.1) will include userland utilities in the > drivers/staging/usbip/userspace folder. Please compile and give > these utilities a go. > > Regards, > > Craig > > > > On 29/03/2012 6:04 PM, flooding Controlled wrote: >> Hi all: >> My linux release is Feodra 16 i686 and I have downloaded the >> linux kernel src with the version 3.1. Then I compiled the >> usbip.ko and usbip_common_mod.ko successfully by (my kernel >> path)/driver/stage/usbip/* . >> And I can load them successfully. >> modprobe usbip >> modprobe usbip_common_mod >> Then I installed the usbip.0.17 by src following the src/REAMME >> successfully. >> Howerver, when I run the command "usbipd", it called the error as >> follow: >> usbip err: stub_driver.c: 33 (open_sysfs_stub_driver) >> usbip_common_mod.ko and usbip.ko must be loaded >> I am puzzled by it. Coule someone give help? Thanks a lot! >> Yours Flooding. >> > > |
|
From: Craig P. <cr...@be...> - 2012-03-29 08:25:29
|
Flooding, The 0.1.7 userland utilities found on sourceforge is obsolete. Your kernel source (3.1) will include userland utilities in the drivers/staging/usbip/userspace folder. Please compile and give these utilities a go. Regards, Craig On 29/03/2012 6:04 PM, flooding Controlled wrote: > Hi all: > My linux release is Feodra 16 i686 and I have downloaded the linux > kernel src with the version 3.1. Then I compiled the usbip.ko and > usbip_common_mod.ko successfully by (my kernel > path)/driver/stage/usbip/* . > And I can load them successfully. > modprobe usbip > modprobe usbip_common_mod > Then I installed the usbip.0.17 by src following the src/REAMME > successfully. > Howerver, when I run the command "usbipd", it called the error as follow: > usbip err: stub_driver.c: 33 (open_sysfs_stub_driver) > usbip_common_mod.ko and usbip.ko must be loaded > I am puzzled by it. Coule someone give help? Thanks a lot! > Yours Flooding. > |
|
From: flooding C. <flo...@gm...> - 2012-03-29 07:35:07
|
Hi all:
My linux release is Feodra 16 i686 and I have downloaded the linux
kernel src with the version 3.1. Then I compiled the usbip.ko and
usbip_common_mod.ko successfully by (my kernel path)/driver/stage/usbip/* .
And I can load them successfully.
modprobe usbip
modprobe usbip_common_mod
Then I installed the usbip.0.17 by src following the src/REAMME
successfully.
Howerver, when I run the command "usbipd", it called the error as follow:
usbip err: stub_driver.c: 33 (open_sysfs_stub_driver) usbip_common_mod.ko
and usbip.ko must be loaded
I am puzzled by it. Coule someone give help? Thanks a lot!
Yours Flooding.
|
360 messages has been excluded from this view by a project administrator.
