On 2012.07.12 19:31, Peter Stuge wrote: > As Pete likes to point out I have no authority in the libusbx > project,
Indeed. Still you seem suspiciously eager to comment as if you had, apparently striving to do it before any of the regulars actually get a chance to reply... I find this as both very rude and damaging, as, seeing that you are not endorsed as a moderator here, yet pretend to be entitled to act like one, it does end up sending mixed messages. Great way to undermine a project that decided to fork precisely because we disagreed too much with your views. At least, now that libusbx is operational, I do have the decency not to try to undermine your authority in libusb. I kind of was expecting the same, but maybe that was just too much to ask from someone with a track record of wanting to impose their control on everything. > so as far as libusbx is concerned I think the best > might be if you could pretend that I had never posted this > feedback on the libusbx list. Peter, rather than pollute libusbx with libusb matters, how about you contact the poster privately first, to see if they want to duplicate their message to libusb. Then you would have the ability to voice your comments there, where they belong. >> I've attached a series of patches, split up into the backend and >> various changes to common code. > > I think you've split too much actually I don't. And I don't think it matters that much anyway. Mixed messages already... >> This backend requires the Windows CE Standard 5.00 SDK. > > * Why? - I mean: What parts of the SDK are required? Here again, I don't think it matters at this stage. Obviously, since we're dealing with new code, we might as well take it one step at the time. So, as far as I'm concerned, 5.00 is fine because *once* we've sorted out 5.00 support, we can try to see about more recent versions. I'd rather concentrate on what matters for now, which is to try to have at least one CE SDK that compiles and can produce something that our users can play with. >> The current limitations of this backend are: >> * It only supports control and bulk transfers. The CEUSBKWrapper >> driver doesn't (yet) support isochronous or interrupt transfers. >> The kernel APIs do exist, so they just need to be exposed to user-side. > > What kind of effort does that require? Not sure this matters in a RERO process. Whether Toby wants to follow through with supporting isochronous and interrupt or isn't that great of a concern as much as long as we have a base. If there is demand for those, then someone, who may or may not be Toby, can take over and we can worry about how much effort will be required then. >> The attached patches are broken down as follows: >> >> 0001 - adds the WinCE backend code and build files. >> 0002 - Updates .gitignore to include the WinCE build files. >> 0003 - Adds support for the WinCE backend to common code. >> 0005 - Updates some time API calls to call the appropriate APIs for WinCE. > > The above should be combined into a single Add Windows CE support patch. Again, don't care. The current breakdown is fine with me, as I prefer getting stuff integrated rather than focus on being a git zealot. >> 0004 - Replaces getenv() with NULL on WinCE due to it not being supported. > > Try to change this in a good way where getenv() is called, instead. > Is there an equivalent to environment variables in Windows CE? Maybe > the registry? The question is in which key the value would be. I'd also prefer if we could have something better than a null getenv(), provided that it's possible. But whether this is being looked at tomorrow or months from now isn't a major concern. > If no, then you can always simply make autoconf check for getenv and > put the code in libusb_init() within #ifdef HAVE_GETENV. Just don't > forget to initialize the dbg stack variable if you go that route. That would indeed be the better approach. Again, Toby, whether you want to do that now or later on is not an issue, as, unlike libusb, we're trying to be RERO, so we'll prefer early integration of a new experimental backend over added delays due to minor implementation details that can be improved later. ------------------------------------------------------------------------- OK, now with regards to what I would have been replying outside of Peter's intervention: 1. This is great. The more backends we have, the better! 2. Obviously, we'll want to flag this backend as experimental for a while after we integrated these changes. But because it'll be experimental, we should be able to get some leeway with regards to the process. I'm hoping we can have some of it in 1.0.13. If not, 1.0.14 should definitely be our target. 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. Also, when you have a fork, you can directly attach patches from your fork to issues raised against the origin. - you create a new enhancement for adding CE support at https://github.com/libusbx/libusbx/issues, so that it's firmly on our agenda, and so that it's publicized. Now, it seems in his eagerness to impose his mark on this integration process, Peter has rushed into commenting on your code. I'm not going to do the same, as I'd prefer reviewing what you've sent at my leisure. However, I'll just comment on the following: >> libusb/os/wince_usb.c | 1222 >> +++++++++++++++++++++++++++++++++++ >> libusb/os/wince_usb.h | 156 +++++ > > How about refactoring the existing Windows code so that everything > that is common between the two systems will exist only in a single > place? I will very much prefer if the CE and Windows code is kept separated. The reason is that we will prefer something that's easier to maintain, and therefore less prone to breakage, over something that will win us first prize in the "looks clean" competition. The Windows backend code source is large enough as it is. > If you consider that infeasible then please sell that a; write > about why, and write about what is different between the normal > windows backend and the wince one. Seriously, what the heck is wrong with you Peter? Someone comes up with something that you just don't like, and now they have to stand trial? And what's more, on a project that you have no authority upon? How about welcoming code in any state and trying to integrate it early so that it can *actually* benefit users? Pointing to sections of code that you think can benefit from an improvement is fine - that's what reviews are for. On the other hand, this attempt to force someone to justify something that is unrelated to code (breakdown of files) just because every time you appear to see something that you subjectively label as "unclean", you try to force your own preference, isn't. You're clearly disputing a matter of mostly subjective preferences here, and even if we were to remove the subjective aspect, the logic of the integration process would likely go against your wishes of something that looks nice and clean. Sorry, but this is not the kind of discussion we want to have on this list: whether the CE code is part of a global Windows backend or separated shouldn't matter to our users as it shouldn't impact performance. And as stated, from a pure maintenance's perspective, I see a lot of advantages in trying to keep things separated, especially as this is brand new development. So please kindly take your "sell us your choice" bullshit elsewhere, while leaving us concentrate on the elements from this patch that will actually matter for libusbx users. Regards, /Pete ------------------------------------------------------------------------------ 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
