On 2012.09.10 08:56, Hans de Goede wrote:
> Note this set does not yet hook up the new kernel ioctl, I would like to
> wait with that until it hits Linus' tree
and
> I know it is a bit late, but if possible I would like to get this in for
> v1.0.13
So this is really 1/3 and 2/3, with 3/3 ("A follow up patch will add use
of the new ioctl") to be produced later, right?
I don't have an issue adding these 2 for 1.0.13 if others want it, but
somehow I feel this is exactly the kind of OS specific calls we want to
avoid adding an extra public API for (since, if the kernel ever
implements something that obsoletes it, we'll have to publicly carry
that call forever). Instead, I see it better suited into a new single &
generic libusb_perform_os_specific_op() or something, that would take OS
specific actions/parameters, but through an API generic that all OSes
can have some use for. I.e. something along the lines of what I proposed
previously (though thinking about it some more, I think an union of
single op's would be better suited than a struct of all of them).
Do we expect any other platforms, besides Linux to ever need
libusb_detach_kernel_driver_and_claim()?
Granted, we already have libusb_detach_kernel_driver(), so yeah, it's a
special case, but from the comments, the call looks awfully OS specific
to me, and therefore something that doesn't seem extraordinarily well
suited to introduce in an API that is intended to be as cross-platform
as possible.
Thus, I would prefer making it less conspicuous, and at the same time
try to sort a once and for all approach for OS specific calls.
I can even use that proposal to elaborate further what I have in mind,
but that's not gonna happen in time for 1.0.13...
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
