From: Pete B. <pe...@ak...> - 2015-03-05 22:32:17
|
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. :) 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. 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... 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. 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 misnommer 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... Regards, /Pete |