On 2012.07.13 12:56, Toby Gray wrote: > Firstly I apologise for sending my message body as HTML, I've clearly > not figured out how to force Thunderbird to always send as plain text.
No worries. Text is more friendly for archiving and dumb processing, so that's what we prefer, but we're not gonna start ignoring messages that are sent to the list as HTML... > I'm happy to try to sort this out now with a registry setting. It's been > annoying me a bit when debugging the library that I can't turn on the > debugging output without recompiling either libusbx or the code calling > into it. The idea behind this, for the log level variable, is that with an environmental/registry variable then even for applications that don't offer the choice of setting logging to debug, we can still get users to toggle a flag on their system and get debug output, which greatly helps troubleshooting. Obviously, we'd like to have that on CE one way or another. And a registry setting instead of getenv should do just fine, as far as I'm concerned. > I've put an alternative fix into the branch which I plan to keep rebased > on libusbx/master: > https://github.com/tobygray/libusbx/commit/4b0f2413ae85d197db8721e2fda5a85355d95e1b > > The only thing I'm not sure of in this fix is that wince_usb.c doesn't > seem like it's quite the right place for it. What do you think? Lately I've been fond of putting generic features that are commonly found on POSIX, and that MS compilers need to emulate, into a custom unistd.h. Most of that applied to macros, but I guess we could extend it provide both a custom unistd.h and unistd.c for the getenv implementation. Now, if Microsoft ever decides to provide an unistd.h we may have some issue, so maybe a missing.h/missing.c would work just as well, and be more explicit. Still, it may be a bit of an overkill to create separate a source if it's just for getenv, and considering that there are probably quite a few generic calls in windows_usb.c that could be better off in a separate source, I'm not sure I have much ground asking you to split that call unless you want to... >> 3. My preference for having this integrated would be that: >> - you create a fork for it on github, based on >> https://github.com/libusbx/libusbx, which is where we have moved our git >> master. The idea is that, if it does take a while before we start >> looking at CE integration, you'll be able to rebase your patches against >> the latest libusbx for when we are ready, and people who follow libusbx >> and want to play with your changes will be able to use the same >> infrastructure. > > I did almost submit the patches this way. I only avoided it as I wasn't > sure if it'd be the desirable way. > > I've created a repository with a WinCE branch here: > https://github.com/tobygray/libusbx > > I've left the original branch that I created there as wince_original as > I've noticed that you've referenced the handle leak fix in the windows > code already. I was planning on sending it as a separate patch, but I'll > just keep the wince_original branch until you've integrated the fix. OK. I can delete the ref in the comment if you want, as it was more of a means to figure out how to reference commits for other github repos in comments (<username>/<project>@<commit hash>) than anything else. If you want to delete the branch, I'll update the reference to point to the master commit in libusbx once I apply it. I'll also do my best to make sure we deal with your patch while it's hot, as it often becomes a lot more time consuming for everybody not to deal with things as they come along. For the record, I have updated the 1.0.13 milestone [1] to mention the CE integration effort. I have also moved the "add testlibusb sample or an ISOC sample" task from 1.0.13 to 1.0.14 as a result (IMO, the least important item we had). Delaying this task shouldn't be much of an issue as we will of course try to accommodate goals when new items come along, Regards [1] https://github.com/libusbx/libusbx/issues/milestones?direction=asc&sort=due_date ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
