Gregory Edigarov <ediga...@qarea.com> wrote: > On Fri, 6 Oct 2023 10:06:15 -0000 (UTC) > Stuart Henderson <stu.li...@spacehopper.org> wrote: > > > On 2023-10-06, S V <ner...@gmail.com> wrote: > > >> The software that you're using may need the USB device to be > > >> attached to ugen rather than uftdi. The simplest way to do this is > > >> probably to type "boot -c" at the boot loader, "disable uftdi", > > >> "quit". > > > > > > > > > Thanks!!! It works!!! > > > > good, thanks for confirming. > > > > > Last "barrier" in front of openhardware > > > > > > more or less falls! :D :D :D > > > > btw, see bsd.re-config(5) if you want this regularly (but then, you > > won't be able to connect to a uftdi device as a normal serial port > > with cu). > > > > Just a small bit of side note, perhaps somebody with knowledge of usb > stack will find it interesting enough to implement. > I think we need a way to detach a specific usb driver from device on the > fly, leaving it attached as ugen. > That "disable [whatever]" way is a problem itself because it is > possible that there also is a real device that needs to be attached.
That seems like what you want, but please consider. Now that you've done that, who is opening that 'raw usb device'? Or is the regular user? Who fully audited the USB stack for this use case, to make sure there are no bugs which can result in escalation or misbehaviour? What happens if a usb device is played with directly, while there is a kernel driver which assumes it has control over it? What kinds of racy bugs lurk in that area? We really have no interlock design allowing such sharing. I can give you the anwers to these questions. Noone did that audit. That is why we have been avoiding going down your chosen roadmanp. When you say "I think we need", you can easily read it as "I think I want" and it means someone must do the not-small job.
