Hostility in plain sight

Posted Dec 21, 2012 2:25 UTC (Fri) by mathstuf (subscriber, #69389)
In reply to: Hostility in plain sight by nix
Parent article: The eudev project launches

Maybe I'm missing something, but why not use /dev/disk/by-id/backup instead of renaming to /dev/backup? It seems prone to being wrong if disks are added/removed from the system.

to post comments

Hostility in plain sight

Posted Dec 21, 2012 9:21 UTC (Fri) by nix (subscriber, #2304) [Link] (9 responses)

Because that
- only works for disk devices
- requires me to figure out whether /dev/disk/by-id works for this particular sort of device
- requires me to compensate for ID string changes across udev upgrades (which have happened, though rarely), adding yet *another* source of pain to udev upgrades
- doesn't actually help with the problem described at all because the /dev/disk/by-id names are still symlinks.

/dev/backup and other such nodes are identified by whatever I see fit and wired in via hardwired udev rules; generally I use the USB device serial number and wire in the partition number explicitly. It has never broken (modulo the now-I-can't-rename-but-have-to-symlink thing).

Hostility in plain sight

Posted Dec 21, 2012 17:37 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

So create /dev/backup symlink or even a hardlink.

Hostility in plain sight

Posted Dec 21, 2012 22:02 UTC (Fri) by nix (subscriber, #2304) [Link] (7 responses)

I don't think you can do hardlinks with udev. I explained why symlinks are worse than a rename (or, admittedly, a hardlink: I don't care if the original device name is still there) a few comments up in the thread.

Hostility in plain sight

Posted Dec 22, 2012 0:16 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

I think it's still possible to catch "add" events and hook up hardlink creation there.

Hostility in plain sight

Posted Dec 22, 2012 0:30 UTC (Sat) by nix (subscriber, #2304) [Link] (5 responses)

What, a direct RUN="ln ..." call? That's beyond gross, tantamount to lying to udev about the state of /dev, the sort of thing I'd expect to cause trouble.

Hostility in plain sight

Posted Dec 22, 2012 1:00 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Yep. So?

Assigning names like /dev/backup is an even bigger hack.

Hostility in plain sight

Posted Dec 22, 2012 5:44 UTC (Sat) by raven667 (subscriber, #5198) [Link] (3 responses)

No. Assigning names to specific devices is exactly one of the use cases udev and dynamic device names were supposed to handle.

Hostility in plain sight

Posted Dec 22, 2012 7:16 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Assigning additional names/symlinks to devices is fine. I quite like various hierarchies by attachments, UUIDs, etc.

However, I also quite like stable and consistent device naming.

Hostility in plain sight

Posted Dec 22, 2012 15:18 UTC (Sat) by HelloWorld (guest, #56129) [Link] (1 responses)

Linux/devtmpfs doesn't give you stable device names, at least some device names depend on the order in which the devices were discovered at boot, which is why most distros today use UUIDs in their fstab.

Hostility in plain sight

Posted Dec 22, 2012 19:07 UTC (Sat) by nix (subscriber, #2304) [Link]

It's trivial to get stable device names of your choosing. Simply set up a udev rule that matches some unique property of the device, and set NAME=... only nowadays you can't do that: symlinking is all you can do.

The UUID stuff is not magic: it's doing just that, only using RUN= to populate some env vars, then assigning symlinks depending on the value of those vars.