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 <g...@lexort.com>
> >
> > Jason Thorpe <thor...@me.com> 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 <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
