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: 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 > > |
