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