How can nerves handle udev rules that are expected to be in place for a custom hardware component?

I have a hardware peripheral that I am trying to add to my nerves device, and the driver (shipped with raspian support) has a udev rules file that I am looking to find a solution with nerves. I dont think nerves uses udev for the hardware, so I am looking for guidance on how to port these udev rules to how nerves wants it to be (mdev?)


Nerves uses the Linux kernel’s devtmpfs support for maintaining the /dev directory. That means that Linux kernel automatically creates device files as requested by device drivers.

When hardware is inserted, removed, changed, or pretty much anything happens to it, the kernel sends uevent messages.

Programs like udev listen for these events and then do a pattern match on a set of rules. The rules can do pretty much anything, but they’re often as simple as setting the permissions on a file in /dev/ so that a normal user can use the device. Sometimes the rules can be complicated. I’d take a look at what their rules do since it may not be something you need on Nerves, and in that case, you can ignore them.

Since Nerves doesn’t run udev and the Elixir programming language has such a nice way of specifying pattern matches, Nerves has support for reacting to uevent messages in Nerves.Runtime. uevent messages refer to devices hierarchically. That hierarchy is replicated in SystemRegistry so that you can trigger off changes to the tree. If you run SystemRegistry.match(:_) on the device, you’ll get the tree. It’s big, though, so I’d run SystemRegistry.match(:_) |> save_value("/root/sr.txt") and then SFTP sr.txt off the device for inspection using an editor.

If this feels like a lot, it’s because it is. This is an area of Nerves that I’d really like to improve. I’ve seen many people punt on using uevents/SystemRegistry and just poll /dev for device files to appear or reappear.



Thanks Frank. That is great direction, I am going to make this respeaker work and blog about it.

1 Like