From: Dmitry F. <dm...@da...> - 2015-03-06 13:13:19
|
> On Mar 6, 2015, at 24:09 AM, Pete Batard <pe...@ak...> wrote: > > On 2015.03.05 08:45, Dmitry Fleytman wrote: >> For convenience, I’ve created libusb fork on github and put patches >> there, see branch usbdk-backend-v1 at: >> https://github.com/dmitryfleytman/libusb/tree/usbdk-backend-v1 > > Thanks for this. I guess I'm going to continue with the superficial > nitpicking for now. :) Hi Pete, > > 1. Why do you need an UsbDk/ subdirectory? We have one for haiku, yes, > but it's mostly because they have quite a number of additional files > (that are C++ rather than our usual C), and they needed a dedicated > configure. On the other hand, UsbDk\ contains only 2 headers and the > current windows_usbdk.h header in parent directory is "empty" (see #4) > > 2. The libusb naming convention for sources is to use lowercase and > underscore. Your UsbDk headers should really be named > "windows_usbdk_data.h" and "windows_usbdk_helper.h" > > 3. Those headers are rather small - couldn't they be merged in a single > windows_usbdk.h (which would also solve #4)? > > 4. What's the point of the current windows_usbdk.h that only contains a > #pragma once? That seems rather useless. The idea behind subdirectory and 2 files with these specific names is that we put headers with API definitions as-is from UsbDk source tree. This was done to simplify future updates of UsbDk headers - plain copy instead of manual merge. However, if you think it is better to have header files that follow libusb guidelines anyway, we will do corresponding changes. > > 5. (This is more of a *strongly preferred* request) Anybody who brings > major changes to Windows is expected to provide and have tested a > working solution for all of MinGW, cygwin and Visual Studio (2013 being > preferred since its Community Edition is freely available). You don't > have to test every individual instance of each (meaning, if you tested > with MinGW32, we're not really gonna expect you to also have tested with > MinGW-w64), but you are strongly advised to provide a working Visual > Studio solution sooner rather than later… Yes, we could do this. > > 6. On that account, what [is|was] your plan to bring the optionality of > UsbDk for Visual Studio? I hope you realize that Visual Studio doesn't > exactly provide users with a configure step to pick features... I guess > we could go with what we did for DLL vs static (one solution > encompassing 2 library projects), but that means we'll have to contend > with 4 project files... multiplied by the number of versions of Visual > Studio we intend to support. The same level of optionality may be achieved by single solution with multiple configurations. In any case, I tend to make backend selection logic run-time instead of compile time. What strategy would you suggest - having additional libusb API for Windows sub-backed selection or extending current libusbk/winusb selection scheme? > > 7. I think we're gonna have to solve the confusion of having something > like windows_common.h + [winnt_common.h|windows_core.h] + windows_usb.h, > because the current designation hardly gives any hind as to what is the > exact purpose of each of these generic headers. Also if Windows gets > broken down between windows_usb and windows_usbdk, I think we ought to > rename windows_usb.c (and possibly windows_usbdk.c), as, per designation > alone, windows_usb is expected to be a superset of anything USB, which > therefore should include windows_usbdk. Thus, we have to find a means to > convey that the new "windows_usb" is really "windows_usb, sans the UsbDk > functionality". Right now, considering that UsbDk is a filter, and the > rest of the interface is aimed at conventional single drivers (with the > exception of libusb0 as a filter, but that doesn't bother me much, since > the prime use of libusb0 is regular) what I'd be leaning on would be to > have a windows_driver.c and windows_filter.c (which of course is > somewhat of a misnomer since a filter driver is still a driver). Or it > could be something else that makes more send. However I don't think we > should continue with windows_usb.c when that source has just lost its > USB genericity… What if we establish naming by API names, i.e. windows_usb.c with support for WinUsb/libusbk becomes windows_winusb.c and UsbDk support stays at windows_usbdk.c? ~Dmitry > > Regards, > > /Pete > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > libusb-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel |