From: Pete B. <pe...@ak...> - 2015-03-08 22:40:35
|
On 2015.03.06 13:13, Dmitry Fleytman wrote: > 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 I would prefer avoiding that. I think it makes more sense to try to keep libusb as a standalone project, that doesn't require specific knowledge of another project to understand our sourcecode structure, and I'm hoping that 2 merged headers in sync is OK. >> 6. On that account, what [is|was] your plan to bring the optionality of >> UsbDk for Visual Studio? > > The same level of optionality may be achieved by single solution with > multiple configurations. True. The only downside I see is that most MSVC users would be used to using configurations for Release/Debug, and little else, so they may not expect the selection to happen there. I'm also a bit partial to having different projects, as we do for DLL and static, as this makes it explicitly clear when a user opens the solution. Then again, I'm the one who introduced this approach in libusb, so I can't say I'm totally impartial here... ;) > What strategy would you suggest - having additional libusb API for > Windows sub-backed selection or extending current libusbk/winusb > selection scheme? Due to the WinUSB-like nature of the libusbK DLL (and the fact that it will also handle libusb0 in a WinUSB like manner), the only selection occurring happens at runtime, according to the driver that is installed for the target device. Of course, since we can't use that for UsbDk, we need a different approach. I guess your question is a follow up to a question you had, which I didn't answer in your previous reply. > There are 2 possible approaches: > > 1. Add explicit API to libusb for selection of the backend > 2. Extend current libusb backend selection logic that selects > libusbk/winusb sub-api based on libusbk is presence in the system. My current thinking is that we seem to have an API that could be used to do exactly the kind of UsbDk driver runtime "override", in the form of libusb_detach_kernel_driver() [1]. As a matter of fact, this is an API that was a bit problematic on Windows, because it looked like a pure POSIX construct that would never make much sense in a Microsoft world... But with UsbDk, this might not be true any longer. If I understand what UsbDk correctly, it looks like detach_driver would fit the bill nicely for giving Windows libusb users the choice of using UsbDk at runtime, by "detaching" whatever regular driver is currently installed, and get the UsbDk filter in. Then when they are done with libusb/UsbDk access, they can call libusb_attach_kernel_driver() to reattach the existing regular driver. Oh and the other nice thing we have going to attach/detach is that we have an LIBUSB_CAP_SUPPORTS_DETACH_KERNEL_DRIVER [2] capability as well, to indicate whether the current libusb supports the feature. So I guess my preference for UsbDk usage would be to have it enabled default (though we can keep the switch to allow people to disable it if they want to), and have libusb app developers rely on libusb_has_capability() and libusb_detach_kernel_driver() to access their devices through UsbDk. Of course this means that someone wishing to update an existing Windows application to always use UsbDk will have to add extra code (as opposed to flipping a switch on library compilation), since those are not expected to use detach_driver(). However, this is probably what we want to ensure that an app that was using WinUSB/libusb0/libusbK continues to do so. And then again, some apps that are being ported to Windows may already use has_capability() and detach_driver(), in which case they will have to add extra code if they don't want to use UsbDk. Now, since I still haven't looked at the details of your proposal, I can't tell for sure if detach/attach is something that would be easy to apply to what you currently have, or if it might be a headache. I'd also like to find out if other people on this list have a strong opinion (or technical flaw) against the use of the existing detach/attach for Windows. >> 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 >> (...) >> have a windows_driver.c and windows_filter.c > > 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? That sounds much clearer than what I was proposing! Unless the libusb0/libusbK people are unhappy to see only the WinUSB name mentioned, I think your proposal is the better solution indeed. Regards, /Pete [1] http://libusb.sourceforge.net/api-1.0/group__dev.html#ga21bd343325f558987ca57e4e281a6d47 [2] http://libusb.sourceforge.net/api-1.0/group__misc.html#gaab1b3fa0728c06fafbee897795889bd5 |