[TUHS] UNIX and USB

[Warner Losh via TUHS]

On Mon, Mar 9, 2026 at 1:05 PM segaloco via TUHS <tuhs at tuhs.org> wrote:

> So USB hits the scene in the mid-90s, the raucous 80s of UNIX had come to
> a close by this point and many original actors and architects were on to
> bigger and brighter things.  In other words, the folks who designed
> terminal handling, block and character I/O, etc. were long since "retired"
> from helming the UNIX ship.
>
> This has me wondering, when USB hit the market, was there any attempt at a
> grand, unified "this is how UNIX does USB" around the industry or was
> implementation of drivers and interfacing largely left to individual shops?
>
> The reason I ask is I'm currently working up some tooling in the UNIX
> tradition for interacting with the RP2040 microcontroller (as opposed to
> their picotool and pico-sdk which are bulkier than what I want).  What I'm
> currently tinkering with is something dd(1)-like that allows indicating
> things like I/O direction, packet type (control, bulk, etc.), payload, etc.
> for a very basic generic USB operation that could then be used on /dev
> files, as opposed to my current approach of writing a libusb-oriented
> monolith.
>
> Was there ever any sort of canonical basic USB packet tools operating on
> /dev entries in the UNIX ecosystem?  Something making USB packet I/O a
> shell affair rather than libusb or custom kernel stuff/ioctls in a C
> application?
>
> Getting this far down into USB is pretty fresh for me BTW, so pardon any
> incorrect assumptions (e.g. whether stateless, individual process
> invocations could even reliably issue sequential USB transfers without
> potential transients introduced between invocations, claims and halt states
> between processes, etc.).
>

libusb has been the convergencec point for different implementations. The
BSDs share a common API (more or less) because the original version was
copied, but then diverged. Linux did its own thing. Other sytems also do
their own thing, though some did port Linux or BSD stack over and diverge.

There never was any attempt to make this be packet driven because that was
a poor fit with ohci/uhci devices IIRC. That is, you couldn't really get
the packats like that and even if you could the different endpoints and the
need to configure made things complicated.

Of course, this is me watching from the sidelines, so maybe I missed
something?

Warner