Hostility in plain sight

Posted Dec 18, 2012 21:14 UTC (Tue) by nix (subscriber, #2304)
In reply to: Hostility in plain sight by Cyberax
Parent article: The eudev project launches

I don't know Al's reasons, but I know mine. It wires policy (device names) into the kernel, just like devfs used to: worse, you can't even change its decisions without hacking the kernel, since udev lost the ability to do a mknod or even a rename() on the nodes devtmpfs creates (sure, I'd agree that renaming /dev/zero is probably a bad idea, but that doesn't mean that *no* kernel-named device node is ever reasonable to rename: indeed I had several renamings that broke when I upgraded udev, with no fix other than kernel hacking or backing the change out of udev).

Also it is plain ugly and inelegant to have a filesystem that magically automounts itself on /dev, and even less elegant to have one that magically automounts itself if and only if you're not using an initramfs (and you've flipped the appropriate kernel config option and you haven't turned it off again on the command line and Saturn is in Taurus).

It's a nasty kludge. It may be necessary for huge installations with many thousands of block devices, but for the rest of us coldplugging worked perfectly well with undetectable delay and let us rename devices if we wanted to (not that devtmpfs broke that, udev userspace did).

Worse yet: amount of documentation in Documentation/ for this profoundly unusual filesystem: nil, as far as I can see. And where's the source code? Is it in fs/? No, it's in drivers/base, the last place one would ever expect to find a filesystem.

to post comments

Hostility in plain sight

Posted Dec 18, 2012 21:58 UTC (Tue) by viro (subscriber, #7872) [Link] (1 responses)

Fortunately, I'd been able to stay with versions of udev that still work without that sucker (more recent ones whine about its absense, but that's it). The headache kernel-side had been there from the day it got merged...

IOW, your reasons are more about disliking current udev dependency on that thing. All valid, and devtmpfs has enabled that shite, but it's not entirely fair to blame devtmpfs itself for it.

That probably was the last time somebody got away with "it's just optional, don't enable it if you don't want it" kind of excuse at merge time, though...

Hostility in plain sight

Posted Dec 19, 2012 14:54 UTC (Wed) by nix (subscriber, #2304) [Link]

True enough. devtmpfs, if built in but not used, doesn't do any harm to me, and even if built in, it *is* possible to rename, delete and mknod nodes: it's just that udev threw that capability away.

Hostility in plain sight

Posted Dec 18, 2012 22:10 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (19 responses)

Device names should have been there from the start.

>you can't even change its decisions without hacking the kernel, since udev lost the ability to do a mknod or even a rename() on the nodes devtmpfs creates
????
You most certainly can rename kernel-created devices in udev scripts.

> It's a nasty kludge. It may be necessary for huge installations with many thousands of block devices, but for the rest of us coldplugging worked perfectly well with undetectable delay and let us rename devices if we wanted to (not that devtmpfs broke that, udev userspace did).
I'm using it on a small devices where it saves a lot of bother with mdev or static device nodes. Also, it has helped me a couple of times with the emergency recovery.

Hostility in plain sight

Posted Dec 19, 2012 14:53 UTC (Wed) by nix (subscriber, #2304) [Link] (18 responses)

You most certainly can rename kernel-created devices in udev scripts.

You cannot. From udev 154 NEWS:

Udev now gradually starts to pass control over the primary device nodes and their names to the kernel, and will in the end only manage the permissions of the node, and possibly create additional symlinks. As a first step NAME="" will be ignored, and NAME= setings with names other than the kernel provided name will result in a logged warning. Kernels that don't provide device names, or devtmpfs is not used, will still work as they did before, but it is strongly recommended to use only the same names for the primary device node as the recent kernel provides for all devices.

From udev 175 NEWS:

The 'devtmpfs' filesystem is required now, udev will not create or delete device nodes anymore, it only adjusts permissions and ownership of device nodes and maintains additional symlinks.

So, no creation, no removal, no renaming.

Hostility in plain sight

Posted Dec 19, 2012 15:14 UTC (Wed) by HelloWorld (guest, #56129) [Link] (17 responses)

I just fail to see why that is supposed to be a problem.

Hostility in plain sight

Posted Dec 19, 2012 16:15 UTC (Wed) by nix (subscriber, #2304) [Link] (16 responses)

Well, yeah, this *is* something that depends on your configuration, isn't it. That's the whole point. Those of us who had depended on it now have it wrenched away. There was warning, but still, this is not by any means the first time udev has lost functionality. It seems like a risk to rely on it for anything at all by this point.

Hostility in plain sight

Posted Dec 19, 2012 17:33 UTC (Wed) by HelloWorld (guest, #56129) [Link] (15 responses)

What does renaming accomplish that can't be done with a symlink just as well? Something like sed -r 's/NAME="([^"]+)"/SYMLINK+="\1"/' will rewrite your rules to create symlinks instead of renaming. I don't think is is a huge deal.

But then, I'm a liberal, you're a self-confessed conservative.

Hostility in plain sight

Posted Dec 19, 2012 19:40 UTC (Wed) by nix (subscriber, #2304) [Link] (14 responses)

What does renaming accomplish that can't be done with a symlink just as well? Something like sed -r 's/NAME="([^"]+)"/SYMLINK+="\1"/' will rewrite your rules to create symlinks instead of renaming. I don't think is is a huge deal.

I am of course now using symlinks, but this is nowhere near as elegant, and those things that attempt to tell me what devices they are having trouble with tend to chase the links and blither about /dev/sd{blah} rather than /dev/backup or /dev/helpfulname, and I have to manually track down what they're blathering about. I didn't have to do that until udev took away the ability to rename: even if the apps chased the links, their error messages remained valid.

I would have preferred it if it didn't now require that everything that accessed devices and emitted errors about them be audited to make sure it's not doing symlink-chasing too.

But then, I'm a liberal, you're a self-confessed conservative.

On the other matter: in my part of the world the Conservatives are the liberals, that is to say, the economically right-wing lot. (And I'm a leftish Liberal Democrat voter, that is to say, not a liberal. :) )

One's emotional inclinations, one's desires in software, and one's political inclinations need not correspond.

Hostility in plain sight

Posted Dec 19, 2012 20:01 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> I am of course now using symlinks, but this is nowhere near as elegant, and those things that attempt to tell me what devices they are having trouble with tend to chase the links and blither about /dev/sd{blah} rather than /dev/backup or /dev/helpfulname, and I have to manually track down what they're blathering about.
OK, I can see why that's ugly.

Hostility in plain sight

Posted Dec 20, 2012 8:53 UTC (Thu) by man_ls (guest, #15091) [Link]

One's emotional inclinations, one's desires in software, and one's political inclinations need not correspond.

Let me put this sentence into my personal QotW. The reason is easy to see if we reason about change (or lack of it): one can dislike change in general, may dislike changes in software, and still desire a change in how the world is run. So the degree of conservatism can vary depending on the subject at hand.

Hostility in plain sight

Posted Dec 20, 2012 9:09 UTC (Thu) by apoelstra (subscriber, #75205) [Link]

> One's emotional inclinations, one's desires in software, and one's political inclinations need not correspond.

To add to man_ls's comment...another reason for this is that we often have very different opinions about how people must behave, how people ought to behave, and how we actually behave.

Hostility in plain sight

Posted Dec 21, 2012 2:25 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (10 responses)

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.

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.