Re: [usbip-devel] Protocol for submitting patches / SVN access
Status: Alpha
Brought to you by:
hirofuchi
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 |