Hostility in plain sight

Posted Dec 18, 2012 7:26 UTC (Tue) by man_ls (guest, #15091)
Parent article: The eudev project launches

Why all the hostility towards eudev? It is just a fork. Forking is a fundamental right, and it doesn't have to be bad necessarily. On github, people fork projects to add features all the time. If the original udev can learn a trick or two from the fork, why not let them play for a while? And, even if nothing comes out of it, it is Gentoo (or the maintainers) who bear the burden of keeping a fork, not you.

There has to be some deep political background to this question, and I suspect the agenda is pushing systemd adoption. Red Hat is seeing their hegemony plans foiled by a myriad of projects such as upstart, eudev and so on; and they have to blame those other projects. After all, every project that Red Hat makes the default in Linux is another reason to hire Red Hat for its engineering knowledge of the plumbings of the platform.

This campaign cannot just be for technical reasons. Is there any other possible explanation?

Hostility in plain sight

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

Oh, it's political, all right, and it *is* about pushing systemd and allied turds as wide as possible, but AFAICS you are mistaking the self-interest of duhvelopers for dark corporate plans. I'm no telepath and I would've stayed as far as possible from those minds in any case, but there's a very simple (and ugly) mechanics involved:
* a project joining that group gets an extra leverage when it comes to pushing changes in past objections. Note that devtmpfs (a piece of code that shouldn't have been merged into mainline, optional or not) had been made mandatory by udev changes. In this case the maintainer is the same guy, but the same cross-reinforcement can work between the "vertically integrated" groups.
* any potential fork is going to play losing game against deliberate API changes. Note that there's libudev and I wouldn't bet a dime on such changes not being consciously used as a weapon.
* the more programs grow dependencies on that stuff, the more leverage these guys get.

IMO it's more about bypassing review than anything else. And it's attractive for some people, unfortunately. And then there are fanboys, but how *those* minds operate is something I won't speculate about.

Hostility in plain sight

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

>And then there are fanboys, but how *those* minds operate is something I won't speculate about.
Pot. Kettle. Black.

Hostility in plain sight

Posted Dec 18, 2012 14:35 UTC (Tue) by viro (subscriber, #7872) [Link] (39 responses)

Explain. And unless I've misparsed you, you'd better have *very* good proof of what you are saying.

Hostility in plain sight

Posted Dec 18, 2012 17:36 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (38 responses)

You're just as comically hostile to the idea of systemd, cgroups and other modern infrastructure developments.

BTW, I'm going to buy GregKH a beer for devtmpfs - it has saved me a lot of time a couple of times.

Hostility in plain sight

Posted Dec 18, 2012 17:56 UTC (Tue) by nix (subscriber, #2304) [Link] (37 responses)

Er, Al's a minimalist who hates ugly code. All his opposition is understandable in light of that.

Hostility in plain sight

Posted Dec 18, 2012 20:11 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (32 responses)

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

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?

Hostility in plain sight

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

I'm also a bastard with deep loathing for fanboys of all kinds. And if somebody sounds as if they are trying to imply that I *am* one of those, they'd better be ready to present a strong proof or very clear retraction. I'm yet to see either.

Cyberax: one word - "западло".

Hostility in plain sight

Posted Dec 18, 2012 21:11 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> I'm also a bastard with deep loathing for fanboys of all kinds.
Well, your anti-fanboism for cgroups (and devtmpfs) is quite famous. I'd say it easily qualifies as 'irrational'.

> Cyberax: one word - "западло".
Which doesn't say much.

Hostility in plain sight

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

What does западло mean?

Hostility in plain sight

Posted Dec 18, 2012 21:41 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

That kinda depends on the situation :) Its meaning varies from "I'm bored with this sh*t" to "I'm above doing this sh*t".

udev in the kernel

Posted Dec 18, 2012 12:14 UTC (Tue) by DonDiego (guest, #24141) [Link]

What happened to your plan to maintain udev in the kernel? I can assure you it would be welcomed by many, probably including the eudev developers...

Hostility in plain sight

Posted Dec 18, 2012 13:14 UTC (Tue) by demarchi (subscriber, #67492) [Link] (10 responses)

I don't mind any fork. The problem is the accusations they make for the program they forked and related ones. This just shows they have absolutely no understanding what they are trying to maintain, yet (smart) people think they are doing a good thing because of past issues they had. See the amount of nonsense that was pointed out in their announcement in the comments here and elsewhere.

I have not relationship with RH and no intention to politically defend it.

Hostility in plain sight

Posted Dec 18, 2012 13:20 UTC (Tue) by man_ls (guest, #15091) [Link] (8 responses)

Even so, if eudev developers are ignorant or just wrong, just educate them. Why take everything they say as "accusations" and get angry? This project might as well be just an educational experiment for them, and it is alright.

Hostility in plain sight

Posted Dec 18, 2012 14:20 UTC (Tue) by ovitters (guest, #27950) [Link] (7 responses)

The explanations have already been given various times. I lurk on various distribution mailing lists, so have noticed that claims are made despite the various explanations by multiple people. The explanations&corrections were given, claim is repeated again.

There is of course no need to get angry.

Hostility in plain sight

Posted Dec 18, 2012 14:39 UTC (Tue) by man_ls (guest, #15091) [Link] (6 responses)

Explaining is not educating. Anyway, the developers will probably realize the errors of their ways now that they have to maintain the project, in those respects where they are wrong. Or reinforce their beliefs if they were right.

Qualifying the forking decision as "hostile", as has been done above, is unnecessary.

Hostility in plain sight

Posted Dec 18, 2012 14:55 UTC (Tue) by ovitters (guest, #27950) [Link] (5 responses)

Could you either explain the difference between explaining and educating or suggest how to educate them?

I'm not sure which of the two have been done, as I'm not sure of the difference.

That someone creates is a fork is totally fine IMO, no reason needed to do so.

Hostility in plain sight

Posted Dec 18, 2012 15:16 UTC (Tue) by man_ls (guest, #15091) [Link] (4 responses)

An explanation is no use if the recipient does not learn what is explained. There are many possible reasons: it may be that whoever explains is using a hostile or condescending tone, or that the reasons given are just weak or untrue. That is assuming that the explanation reaches the recipient at all. I don't know what is the case here, but "explanations have been given and ignored" is not good enough.

I am not (god forbid) a udev expert. From a quick scan of the announcement and the comments here and there, I see many valid reasons and others that have been refuted. The top reason:

The systemd developers are uninterested in providing full support in udev to systemd alternatives.

seems valid to me, especially after Poettering has accused other distros of fragmenting the Linux ecosystem. I may be wrong, but the hostility I see here reinforces the feeling. Anyway it is good to keep an eye about modifications to udev; and keeping a fork is cheap these days.

Hostility in plain sight

Posted Dec 18, 2012 15:27 UTC (Tue) by ovitters (guest, #27950) [Link]

Thanks for taking the time to educate me :)

Hostility in plain sight

Posted Dec 18, 2012 20:11 UTC (Tue) by HelloWorld (guest, #56129) [Link] (2 responses)

The top reason:
The systemd developers are uninterested in providing full support in udev to systemd alternatives.
seems valid to me,

It's a total red herring. udev works just fine without systemd and that isn't about to change. Poettering even praised the cooperation with Ubuntu's udev maintainer.

Hostility in plain sight

Posted Dec 21, 2012 7:45 UTC (Fri) by felipec (guest, #75494) [Link] (1 responses)

And he also said he was looking forward to the day when this stops and udev only works on systemd.

The only reason he is OK with udev working without systemd *for now*, is that it advances his agenda, and it's doesn't really require much effort.

Hostility in plain sight

Posted Dec 21, 2012 17:58 UTC (Fri) by HelloWorld (guest, #56129) [Link]

> And he also said he was looking forward to the day when this stops and udev only works on systemd.
So? If he intended to drop support for udev on non-systemd systems, he could have done it already. He didn't, and other than one off-hand command in one email, there's no indication that he will in the forseeable future. OTOH, he and Kay Sievers repeatedly confirmed that they *will* keep udev working on non-systemd system. Who are you to accuse them of such a blatant lies?

And even if they do drop support for non-systemd systems (which wouldn't be a huge loss anyway, I might add), people should fork *then* and not now.

Hostility in plain sight

Posted Dec 21, 2012 7:48 UTC (Fri) by felipec (guest, #75494) [Link]

Either way it's the fault of udev developers in the first place for not listening to their users, and forcing them to fork.

It's funny how people say "if you don't like it, then fork; it's open source", and then when they do "oh, but you don't know what you are doing". The original developers probably didn't know either, it's only with time that they learned enough to be udev developers.