Hostility in plain sight

Posted Dec 18, 2012 20:11 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
In reply to: Hostility in plain sight by nix
Parent article: The eudev project launches

Devtmpfs is as minimalistic as it gets. Yet he still hates it. Why?

to post comments

Hostility in plain sight

Posted Dec 18, 2012 21:14 UTC (Tue) by nix (subscriber, #2304) [Link] (22 responses)

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.

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.

Hostility in plain sight

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

Read it someday, would you? The logics around the removal (or non-removal) of directory trees in there is really nasty, and I'm not talking about the implementation - semantics from hell, no matter how you implement. For a long time it also had been a constant source of headache for fs/namei.c interfaces; took quite a while to get it more or less tolerable in that respect. In the form it went in, it had been amazingly bad. A lot of races is avoided these days *only* because it's serialized to hell and back. Besides, it's very unfriendly to containers. By design.

Hostility in plain sight

Posted Dec 18, 2012 23:21 UTC (Tue) by HelloWorld (guest, #56129) [Link] (7 responses)

> Besides, it's very unfriendly to containers.
How does it affect containers?

Hostility in plain sight

Posted Dec 18, 2012 23:46 UTC (Tue) by viro (subscriber, #7872) [Link] (6 responses)

It's a single-tree filesystem; *any* container mounting it will see the same system-wide tree. And yes, sysfs suffers the same problem (and that's one of the reasons why sysfs sucks by design), but there's it's somewhat alleviated (at the price of rather gross hacks). devtmpfs simply exposes the same directory tree, no matter which container has mounted it.

It's less of an issue than for sysfs (there we have network interfaces exposed, which hurts a lot more) and the most immediate problem has an fs of its own (devpts), but it's going to cause trouble as soon as container folks get serious about per-container block device visibility, etc.

I'd chalk that up to "lousy design likely to cause PITA for kernel work". Note that the only reason the problem exists at all is that this thing has been put kernel-side. And yes, we can kill the single-tree part of that mess, but then we'll get another source of headache with deciding how to propagate creation/removal events.

And no, that's not the only problem with that sucker.

Hostility in plain sight

Posted Dec 18, 2012 23:55 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Interesting, thank you.

Hostility in plain sight

Posted Dec 19, 2012 0:49 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Oh, come on.

udev in containers is no better than devtmpfs. And besides, you can simply enumerate device nodes by going through all major/minor numbers and be done with it.

Real namespacing of kernel resources is required in any case. And not a window dressing you're proposing.

Hostility in plain sight

Posted Dec 19, 2012 1:25 UTC (Wed) by viro (subscriber, #7872) [Link] (3 responses)

Liar^WPolitician, do show me where the hell have I proposed any kind of "window dressing" regarding the interaction of udev or devtmpfs with containers. What I'm saying is that this thing (among its other problems) is going to be a source of PITA for container folks. And again, that's _not_ the only problem with it, lest you feel tempted to spin it that way.

Hostility in plain sight

Posted Dec 19, 2012 3:30 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

So you're admitting that udev/devtmpfs problems are not the result of devtmpfs/udev design, but are fundamental issues that would have to be tackled on.

Then why so much hate at devtmpfs? It's certainly not mandatory and it's useful for a wide class of users. Its source code is simple and short (yeah, it probably should be moved to /fs directory).

I kinda don't understand what criteria you're applying to 'good' vs. 'bad' design. I suspect it mostly is "if it makes someone's life easier than it's a bad design".

Hostility in plain sight

Posted Dec 19, 2012 4:36 UTC (Wed) by viro (subscriber, #7872) [Link] (1 responses)

You, sir, are a shameless liar.
1) devtmpfs problems include lousy semantics of directory removal. As I clearly said in this thread. The only "fundamental issue" here is that of crap not getting enough review.
2) devtmpfs problems include being extremely sloppy piece of code, both at the moment of inclusion and later, despite fixes of some of the problems [bet this shit will selectively quote up to the words "moment of inclusion" and claim that I admit it's good now]
3) sufficiently recent udev *does* make devtmpfs mandatory. As you very well know.

Hostility in plain sight

Posted Dec 19, 2012 5:05 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

>1) devtmpfs problems include lousy semantics of directory removal. As I clearly said in this thread. The only "fundamental issue" here is that of crap not getting enough review.
Doesn't matter for devtmpfs' purposes. Also, udev has lousy directory removal properties too.

>2) devtmpfs problems include being extremely sloppy piece of code, both at the moment of inclusion and later, despite fixes of some of the problems
What exactly is lousy there? It's a small 450-line skeleton FS. There's nothing complicated going on there.

Can you be even less specific?

> 3) sufficiently recent udev *does* make devtmpfs mandatory. As you very well know.
Ah, I've been using udev-172 on my devices. Looks like it's time to upgrade, I'm glad they're now relying on devtmpfs.

You can easily re-add support for new node creation in udev. But why bother? What exactly are you planning to achieve that way?