On 2012.08.31 15:42, Ludovic Rousseau wrote: > If I understand correctly you want to provide functions/services > specific to an OS. The same function would not be available for > another OS. Am I right?
Yeah, though in this instance I'm thinking more about properties/attribute than function calls. I don't currently envision that we're going to run into USB related OS specific calls that can't be handled through the setting/readout of an OS specific property. > How our users are supposed to use such functions in their code? > > #ifdef OS1 > use the specific function > #else > #error "The program can only be compiled on OS1" > #endif I should have pointed out that my concern with this approach is that we're likely to end up with feature creep, especially if we try to mimic some OS API calls on Windows, as we're pretty much guaranteed to have to introduce a windows_set_feature_ex(WINDOWS_STRUCT_EX param) besides an existing windows_set_feature(WINDOWS_STRUCT param), if we go with separate function calls. Plus, maybe we'll manage to maintain just a handful of calls for each OS, or maybe we'll need a few more than that, in which case the API could be overshadowed with OS specific calls. This is basically the reason why I'd prefer keeping everything in one place, and under single libusb call, that would do the triaging. Would also probably help with documenting the calls, as all the OS specific features would be mentioned in the same place. Also, if we go with individual function calls for each OS feature we want to provide, we'll be stuck with all these calls forever. > Or the function would be available for all the supported OS but would > return LIBUSB_ERROR_NOT_SUPPORTED? That's something we would have to decide if we go with your approach. For instance, I believe the querying of a driver name is something we'd like to have at least in both Linux and Windows, so it would make sense to have a common call that returns NOT_SUPPORTED on *BSD of wherever. On the other hand, the setting of WinUSB policies is something that probably won't translate to well for other platforms, so I'm not sure we'd want a global API call that would return NOT_SUPPORTED on anything but Windows, even more so as we'd have to define the property parameters we want to enable/disable for other platforms. 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
