tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Forcing a USB device to "ugen"



On Tue, Mar 26, 2024 at 12:25:07AM +0000, Taylor R Campbell wrote:
> > Date: Mon, 25 Mar 2024 19:47:31 -0400
> > From: Greg Troxel <gdt%lexort.com@localhost>
> > 
> > Jason Thorpe <thorpej%me.com@localhost> writes:
> > 
> > > I should be able to do this with OpenOCD (pkgsrc/devel/openocd), but
> > > libfdti1 fails to find the device because libusb1 only deals in
> > > "ugen".
> > 
> > Is that fundamental, in that ugen has ioctls that are ugen-ish that
> > uftdi does not?   I am guessing you thought about fixing libusb1.
> 
> It is possible that we could kludge some horrible hacks into ucom(4)
> to pass /dev/ttyU* ioctls through to uftdi(4), but not all USB drivers
> even have a /dev node that could be hacked up in that way.  Really,
> there is a general fundamental limitation with NetBSD's USB stack:
> user programs have no way to take over USB devices from kernel
> drivers.
> 
> We should really expose a /dev/ugen* instance for _every_ USB device;
> those that have kernel drivers attached have only limited access via
> /dev/ugen* (no reads, writes, transfer ioctls, &c.), until you do
> ioctl(USB_KICK_OUT_KERNEL_DRIVER) or whatever, at which point the
> kernel driver will detach and the user program can take over instead
> and use the full ugen(4) API.
> 
> This is how it works in other systems like Linux with
> USBDEVFS_CLAIMINTERFACE, and that's the model that libusb is built
> around.  It's a nontrivial change to our USB stack requiring some care
> to get right, but this is far and away the biggest shortcoming of our
> USB stack and we should unquestionably do it.

Strongly seconded. 

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--


Home | Main Index | Thread Index | Old Index