From: Pete B. <pb...@gm...> - 2010-04-15 19:44:30
|
On 2010.04.15 19:34, Michael Plante wrote: > Well, one way to deal with this question is as follows. Is there a kernel > driver in Windows that we're not allowed to detach, or does it simply not > exist? I think the question is, what does attaching/detaching a kernel driver actually mean on Windows. First of all, the "kernel" from attach/detach_kernel_driver comes from Linux. On Windows, we have "user-mode" and "kernel-mode" drivers, which, against which, for the purpose of libusb, we don't really differentiate (I think both HID and WinUSB are user-mode, but they might as well be kernel-mode and it wouldn't change a thing), so talking about kernel driver is confusing. Then the attaching terminology is also something that I believe comes primarily from Linux. The only place I've seen attaching/detaching mentioned on Windows is with the concept of filter drivers. Now, if we use the Linux meaning, and consider that detach_kernel_driver on Windows means "prevent another Windows driver from interfering with 'native' access of the device required by libusb" (native being WinUSB or HID in our case), then you might have a point, although developers might then expect that a non libusb based application using as user driver on top of HID for instance, and trying to access the same device, would be unable to do so, because the call to detach_kernel_driver was successful. And of course, Windows and OS-X developers will then be supposed to know what was the intent behind these functions call. In short, I think it boils down to what a developer would expect a successful call to attach/detach to do. If the developers come from a Linux world, they'll probably know that these functions probably do nothing on Windows/OS-X and disregards the return value. The ones not so familiar with Linux on the other hand will probably be left perplexed by both what the function is meant to do, and what the return value actually means (unless we add a big "Valid only for Linux - returns SUCCESS on all other platforms" in our doc, which we probably need to do regardless), and this is what I am concerned about. For that reason, I tend to prefer more explicit code with regards to which calls apply to which platform, because then anybody who reads the code knows exactly what is and what isn't relevant for their platform, whereas a Windows or OS-X only developer that takes a look at the xusb source for instance would see a call to detach_kernel_driver always and wonder why such a call seems to be necessary (unless we keep the #ifdef, which I'm planning to do even when the function returns success). Didn't think that would be much of an issue, but since I hear the cries of people who think they would feel constrained by this, I don't have much of an issue granting their wishes. > But I can deal with whichever way you decide to do it. The above just seems > most logical to me. And I reckon it's the easiest way to go from our perspective (potential reduction in ifdefs - and an API that looks multiplatform enough), which I why I said I would change the return value to SUCCESS regardless. Regards, /Pete |