Re: [Libusb-devel] Re: re-attaching device to kernel driver after usb_detach_kernel_driver_np()

[Paul K. <pau...@su...>]

Michael Bender wrote:
> Paul Klissner wrote:
> 
>> Michael Bender wrote:
>>
>>> Paul Klissner wrote:
>>>
>>>> Speaking of this, can anyone specifically state what the
>>>> usb_detach_kernel_driver_np() function is supposed to do?
>>
>>
>>> My personal opinion is that it is wrong to put such a
>>> function into libusb [...]
>>
>>
>> I don't believe many USB subsystems offer this kind of flexibility
>> yet.  Hopefully most them will get there.  Case in point, someone
>> has an accessibility enhancing HID device that at times should be
>> treated like a mouse by the OS, and other times should be owned
>> by a libusb-based driver.  The device's USB "Interfaces" don't lend
>> themselves to shared ownership of critical device features among
>> multiple owning drivers.  So being able to select which driver
>> is active for the device dynamically by the application is critical
>> to the application.
> 
> 
> No, this is also wrong. If the device needs to be shared by both
> the kernel HID driver and some userland program using libusb,
> then the *kernel* driver needs to provide the appropriate
> interfaces for the userland code to do it's dirty work. Playing
> the attach/detach from kernel driver game is just horrible from
> both an architectural point of view (it shows that someone
> wasn't thinking far enough ahead when they designed the kernel
> HID driver) and it's also prone to causing user confusion if
> a libusb application decides to detach this device from the
> kernel driver so that other apps that are currently using the
> kernel driver get failed or stalled I/O. You have to have one
> single owner of the device - usually if you need to drive the
> device with a kernel driver, let the kernel driver be the
> owner, and then let that single owner provide access to other
> clients such as libusb.

I wasn't stipulating architecture at all; that's a whole 'nother
discussion. I'm using 'owned' real loosely because I've not delved
into the mechanisms outside of libusb that will proxy feature control.
While I think your proposal is viable and informative, it is also
a bit out of scope, particularly since I'm merely trying to rule out
libusb as the place to put the interfaces.

I'm was also bringing a customer requirement to bear on the discussion
because I need to give one that has strongly requested the interface
a thumbs up/down reply as to whether the function(s) will be part of
libusb 1.0, and the answer is clearly "no".  I was trying to be gentle.

>> It would be convenient if platform-specific driver attach/detach
>> functionality could be abstracted through libusb, [...]
> 
> 
> No, that would also be a bug since that whole concept is just
> plain bad practice. It may have been fine in "the good old
> days" when we were all writing DOS TSRs in TurboC and x86 asm
> to fiddle around with the hardware like this, but this is
> almost twenty years later - have we learned nothing in the
> interim two decades?

Purely sentimental; I empathize with the wishful thinking.
I also think a money tree be on my porch would be convenient.

> 
>> but practically speaking it confuses the jurisdiction of
> 
>  > God and Caesar (to run ragged the cliche'), as you described.
> 
> God and Caesar, both salad-loving folk in their own right,
> would toss their spiritual cookies as they tried to do the
> libusb kernel-driver-detach genuflect dance in the pews.
> 
>> So I think you're right, such applications need to be platform
>> aware and use platform-specific interfaces to accomplish their
>> driver administration goals.  Even if libusb were the right place
>> to do this, it would still be premature to add the function, due to
>> the general lack of platform support for it in the industry today.
> 
> 
> It would be wrong to have to use this function at all. [...].

No disagreement there.

Paul