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