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