New book chapter -- Dealing with devices

[Michael Wimble]

First draft. Let me know if it’s useful, confusing, has errors.

[Nathan Lewis]

Did a quick runthrough and this has a lot of good stuff in it!

My only big nit is that I feel we really, really ought to stop advising people to change the mode of device nodes to 0666. This is basically just disabling any semblance of access controls for those devices. We should be advising people to ensure the user they're running their programs as is a member of the proper access groups -> "dialout" for serial devices and spidev, "i2c" for i2c devices, "input" for input devices, "video" for video devices, "audio" for audio devices, etc.

A simple "sudo usermod -a -G video,audio,input,dialout,i2c username" would fix all of these access issues for most people.

A bit of an explanation for anyone else reading - those numbers correspond to the basic access control bits. Every file/directory has an owning user and and owning group. The first octet is beyond the scope of a simple explanation (suid bit, sgid bit, sticky bit), and if you write the 3-octet variant (e.g. "666") the zero is implicit. The second octet corresponds to permissions for the owning user, the bits representing "read", "write", and "execute". "6" would mean readable and writable, but not executable. "5" would mean readable and executable, but not writable, and so on. The third octet are permissions for any user that is a member of the owning group, and the fourth are permissions for any other user. Sometimes you see these numbers representing in a friendlier way, for instance "666" could be written as a+rw, "500" could be written as "u+rx", and so on.


Some minor (subjective) nits:

As one of the maintainers of the PlayStation gamepad drivers (hid-sony, hid-playstation), I beg you, please do not write any more code that uses /dev/input/jsX device nodes. It's an extremely old interface that was superceded nearly 20 years ago, has been deprecated for 10 years, and is only officially maintained for legacy devices. Evdev (those /dev/input/eventX nodes) does everything joydev did and more - rumble, motion sensors, etc. I would prefer that newcomers never learn about the existence of joydev.

Yes, the ROS 2 "joy_linux" node for some god awful reason does use the joydev interface, but it seems that the default node that is used ("joy") uses the SDL 2 gamepad library which absolutely uses evdev (I'd know, I wrote some of it =P ). I might just have to go fix joy_linux...

Also the comment: "macOS uses a different device naming scheme and doesn't support udev rules directly". That'd be like saying Windows doesn't support udev rules. The only operating system that can use udev is Linux, and as you noted, not all Linux-es use udev :)

- Nathan

[Nathan Lewis]

Oh, one more thing. I noticed a sample udev rule to generate a fixed name for a block device.

udev for the most part already creates these for you:

For all systems:
/dev/disk/by-uuid/* are symlink to block devices by filesystem uuid
/dev/disk/by-label/* are symlinks to block devices by filesystem label (e.g. /dev/disk/by-label/root)

For systems with GPT formatted disks (if you have a UEFI based system you have GPT formatted disks, if you have a Raspberry Pi you have DOS/MBR formatted disks):
/dev/disk/by-partlabel/* are symlinks to block devices by partition label (GPT optionally has labels in the partition table, doesn't depend on filesystem type)
/dev/disk/by-partuuid/* are symlinks to block devices by partition uuid (GPT has per-partition uuids in the partition table, doesn't depend on the filesystem type)

For instance, on my Raspberry Pi 5:

/dev/disk/by-label:
total 0
lrwxrwxrwx 1 root root 15 Dec 31 1969 system-boot -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 Dec 31 1969 writable -> ../../mmcblk0p2

/dev/disk/by-uuid:
total 0
lrwxrwxrwx 1 root root 15 Dec 31 1969 3631-E742 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 Dec 31 1969 5b8decb9-2a5b-48fa-966b-673b9a731c1f -> ../../mmcblk0p2

- Nathan

[Michael Wimble]

Thanks. Good stuff there.

> On Nov 24, 2025, at 11:33 PM, Nathan Lewis <rob...@nrlewis.dev> wrote:
>
> Did a quick runthrough and this has a lot of good stuff in it!

> --
> You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/2065668.usQuhbGJ8B%40enceladus.