It ain't elegant, it is bodge_

I was working on a USB-library suited to Nerves and needed to name it during development. It felt kind of funny so I picked circuits_usb. We have a bunch of, I dare say simpler, protocols supported under the circuits umbrella. GPIO, SPI, UART. USB feels like 5 hops up in complexity but given that the model for these libraries is to rely on the kernel for a lot of the work it doesn't end up being that much more complex. So the name almost felt right.

Except I don't know USB and I built the darned thing heavily with Claude. Frank actually checked in, very kindly, with me about my intentions for long-term maintenance and care for it if I was to release it under circuits. And as I indicated early, I hadn't exactly sweated the name. I just needed a label. And I don't know my intentions with the library yet. So circuits_ is not the level of dedication.

So introducing bodge_. A bodge-wire is typically a wire added to fix a bug in a circuit board. Appropriate eh, inelegant but makes shit work. Not the level of craft you brag about but often sufficient. A namespace that I can use for what I think are pragmatic, useful libraries that try to do a serious job but where I'd never have made them if I couldn't delegate much of it to an agent. I know people feel several ways about LLMs. I do as well. I find them incredibly useful, surprisingly capable and of course built on a completely rotted unethical foundation. So yeah, chewing on that continuously. Don't think it doesn't bother me. I also don't think software development will ever look quite the same as it has.

First out bodge_usb. Compared to hid which I forked from a lapsed repository to get my Streamdeck working in a cross-platform way from Elixir. This is instead only working on Linux though it should work fine on just about any Linux since it just requires usbfs. The NIF part is as small as feasible while still covering all the things you want to do to a USB device.

One of the most important patterns I end up using when doing stuff like this where I don't know the protocols, specs and standards and I don't have strong opinions is to start with "how can I test this? how can I build confidence in it?" and my previous work with qemu has made me way more comfortable about using VMs and virtual devices. So I was thinking maybe I can use a virtual USB bus. BUT it turns out I have Linux as my boundary and the Linux kernel has plentiful support for dummy USB devices and test USB devices.

The real reason to build this was to build NetMD which isn't labelled bodge_ because I don't expect there will ever be a competing implementation and the name is just very clean. It is a port of existing NetMD MiniDisc over USB efforts from the JS and C libraries. And it was my first and only real test of driving a USB device from bodge_usb. Worked without a hitch. Playing and pausing my MiniDisc player from iex fucking rocked.

With a lot of USB implemented already some opportunities sort of presented themselves. What if we could help people build USB devices? Gadget mode is already used in Nerves to do networking over USB for devices that can. But maybe you want to also expose a storage area or an audio device or some other well-known class of USB device. bodge_usb_gadget lets you do this using configfs.

And because I wanted a virtual NetMD device I dug one layer deeper and more custom and found Linux's functionfs which lets the library let you make custom USB devices. So you get to write both sides if you need to.

Another library that I built prior to adding the bodge prefix but that works on a similar scheme, lots of test harness, lots of LLM, lots of adversarial agent review. Is arrow. An Apache Arrow implementation in pure Elixir. Which should let us integrate with some pretty cool ecosystem bits for zero-copy analytics workloads. I think the biggest value is cases where you have data in Elixir and want Arrow data. I'm thinking of using it for some stuff with Mobius exporting for example. To do Arrow I needed FlatBuffers. So they flatbuf is available if you need it. There are some limitations. They don't 100% every bit of featureset currently and I think the bounds are reasonable. Lots of test coverage in there but I haven't production-proven any of this yet.

bodge_hailo is currently cooking for providing proper support for the Raspberry Pi AI Kit/HAT variants. It is a fork of nx_hailo where I add a bunch of stuff in the way I think I need them. nx_hailo will likely be more steady but with Hailo shitting the bed about compatibility between 8/10 series hardware vs 4/5 series runtime I think things will be messy for a while.  I think I'm the only one who has time to move it forward right now and I'd rather not drown Paulo and Vittoria in my churning agent-driven code.

That is a massive challenge in this stuff. It is trivial to denial-of-service another developer. You have a bunch of context in your head, you've produced a bunch of code and whether you wrote it or not they can't just stamp it OK and merge it, feeling good about it.

You can check the NBPR PR for Hailo support as well. In the end adding your AI accelerator to a Nerves project might not require any customization of the system and you just add {:nbpr_hailo8, "~> x.y.z"} to deps and rock on.

Now I'm going to Liseberg with the family. Have a lovely weekend.

I really appreciate you reading this, thanks.