Re: [usbip-devel] Protocol for submitting patches / SVN access

[Ricardo G. da S. <ca...@gm...>]

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