LWN: Comments on "The eudev project launches"

The eudev project launches

hummassa — Sun, 23 Dec 2012 03:16:58 +0000

You should re-read the whole thread.

Hostility in plain sight

nix — Sat, 22 Dec 2012 19:07:12 +0000

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

HelloWorld — Sat, 22 Dec 2012 15:18:03 +0000

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.

The eudev project launches

ovitters — Sat, 22 Dec 2012 12:42:01 +0000

Your behaviour towards Lennart is really poor. hint: he corrected claims. you just suggest bad intend. Meaning, getting personal, yet again.

Hostility in plain sight

Cyberax — Sat, 22 Dec 2012 07:16:02 +0000

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

raven667 — Sat, 22 Dec 2012 05:44:03 +0000

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

Cyberax — Sat, 22 Dec 2012 01:00:38 +0000

Yep. So?

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

Hostility in plain sight

nix — Sat, 22 Dec 2012 00:30:58 +0000

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

Cyberax — Sat, 22 Dec 2012 00:16:00 +0000

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

Hostility in plain sight

nix — Fri, 21 Dec 2012 22:02:48 +0000

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

HelloWorld — Fri, 21 Dec 2012 17:58:13 +0000

> 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.

The eudev project launches

mathstuf — Fri, 21 Dec 2012 17:50:09 +0000

If it's related to poorly supported hardware, that makes it more understandable as to why I've not had such issues enough to make me feel like I'm risking weeks of "fixing the machine" stuff by running Rawhide.

I did had to keep building the rtl8192se drivers from staging to get my netbook to do much of anything with wireless (and they were flaky, but that's better than nothing). Luckily it's upstream now and the only problem has been that I had a wired interface listed first in the list of interfaces wpa_supplicant was to manage (who knew that wired interfaces didn't support WPA2 :) ). Other than that, things have been fairly solid from kernel land.

As for non-sucky gigabit NICs, I think my desktop machines have the support, but I don't think the rest of the stuff I use supports it, so maybe the gigabit-ness parts never got tickled.

Hostility in plain sight

Cyberax — Fri, 21 Dec 2012 17:37:23 +0000

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

The eudev project launches

nix — Fri, 21 Dec 2012 09:35:07 +0000

It's my dev box, yes (or rather the server which runs my development VMs and Emacs, since I don't actually like rebooting that much: it also happens to be a router between two halves of my local net).

I'd say that 90% of the issues on that machine have been NIC related. If I could have gone back in time to the time I bought the box and picked something other than an e1000e, I would have -- not only did this allegedly server-class box (with ECCRAM and hardware RAID) come with what turned out to be workstation-class 82574Ls wired into the motherboard, the things have had at least two nasty (link dead after a while, reboot required) unfixable firmware bugs requiring driver workarounds, and have had at least three bugs in the drivers breaking things like jumbo frames (which doesn't seem too bad until you realise that the *other* machines on the same subnet will still be using jumbo frames, whoops). I actually have to keep an eye on the log for drivers/net/e1000e these days to make sure that nothing *else* broke on each release. Probably as many as 75% of my upgrade problems come down to that one model of NIC on that one machine. (And yes, I report these problems when uncovered unless someone else has done so first.)

Perhaps the out of tree drivers would work better, but I have a general rule never to use out of tree drivers unless absolutely unavoidable -- the pain factor is just too high, particularly since I prefer non-modular kernels, especially for something critical to system function like the network card.

The question is, are there any gigabit NICs out there which don't suck? r8169 seems OK at first sight but has had rumours of very bad performance in the past, and even security problems where people able to send arbitrary Ethernet packets can cause the card to DMA over arbitrary memory.

'cos it's sort of stupid that with all this advanced and complex hardware in modern machines, and with rarely-used stuff like an Areca RAID card in one machine, the piece of hardware which causes me most trouble is not any of that but a widely-used model of NIC.

Hostility in plain sight

nix — Fri, 21 Dec 2012 09:21:36 +0000

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).

The eudev project launches

felipec — Fri, 21 Dec 2012 07:50:35 +0000

I have a hang that happens very often, and it's not the "firmware issue".

Hostility in plain sight

felipec — Fri, 21 Dec 2012 07:48:13 +0000

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.

Hostility in plain sight

felipec — Fri, 21 Dec 2012 07:45:13 +0000

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.

The eudev project launches

felipec — Fri, 21 Dec 2012 07:42:40 +0000

The kmod changes are *optional*, how is that hard to understand? Build eudev with --enable-kmod and you have *exactly* the same behavior as original udev.

The eudev project launches

felipec — Fri, 21 Dec 2012 07:35:49 +0000

Completely true, in fact, there are other projects using Linux's kbuild system; buildroot.

The only way to make a software project work for everyone, is to allow configuration options for everyone. If you don't, for laziness, or whatever reason; forks are bound to happen, as eudev demonstrates.

The eudev project launches

mathstuf — Fri, 21 Dec 2012 02:45:05 +0000

> and even so it goes wrong about a third of the time when jumping to a new major kernel release and I have to scramble back down and submit a bug report

I have less issues than that running Rawhide. Is this on your development machine(s) or some special use-cased machine (e.g., database server, heavily loaded machine, etc.)? Do you typically do development closer to the kernel such that it matters more? The things I use constantly that depend highly on the kernel tend to be VirtualBox-OSE or GPU drivers. Other than that, GCC, Python, and Boost are probably my biggest on-upgrade problem causers.

Hostility in plain sight

mathstuf — Fri, 21 Dec 2012 02:25:05 +0000

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.

The eudev project launches

Jandar — Thu, 20 Dec 2012 22:14:02 +0000

> People don't read disclaimers. Nor should they have to.

Average people shouldn't forced to read disclaimers but distribution maintainers should. Distributing KDE 4.0 was a irresponsible decision for any distribution catering normal users.

The eudev project launches

HelloWorld — Thu, 20 Dec 2012 21:12:45 +0000

I just realised that that quote even clearly says that KDE 4.0 is meant to be used:

> KDE 4.0 is only expected to be used by early adopters
An early adopter is *not* a beta tester and shouldn't be treated as such.

The eudev project launches

HelloWorld — Thu, 20 Dec 2012 21:07:32 +0000

> KDE got a huge amount of flak even though the beta-status of 4.0 was announced beforehand.
You really don't get it, do you? Nobody reads that crap you've been quoting. It's really, really simple: if it's not a proper release, don't call it 4.0. No ifs, no buts, just don't do it.

The eudev project launches

bronson — Thu, 20 Dec 2012 20:02:42 +0000

Please. All this has been hashed out to death and ignored before.

The KDE4 lesson is simple: if something's not ready for release, don't put a .0 on it.

People don't read disclaimers. Nor should they have to.

The eudev project launches

Jandar — Thu, 20 Dec 2012 19:40:33 +0000

> You can't fix poorly-chosen terminology by explaining it afterwards, it just doesn't work. KDE got a huge amount of flak for calling a beta release "4.0".

KDE got a huge amount of flak even though the beta-status of 4.0 was announced beforehand.

excerpt from http://www.commit-digest.org/issues/2007-12-30/ :

Before everyone starts to spread their opinion about KDE 4.0, let me spread some reminders:
KDE 4.0 is not KDE4 but only the first (4.0.0 even non-bugfix) release in a years-long KDE 4 series to come.
KDE 4.0 is known to have missing parts or temporary implementations (eg. printing, PIM, Plasma).
Most changes happened under the surface and cannot be discovered in a "30 minutes usage" review anyway.
User interfaces being unchanged in 4.0 compared to 3.5 may be still changed/improved during KDE 4 life time.
KDE 4.0 will not be the fastest KDE 4 release - like for KDE 2 most speed optimizations will happen later during KDE 4.
Most applications (many are not even fully ported yet) will take only advantage of new features which the new Qt/KDE libraries offer later.
Don't measure portability success (eg. MS Windows) by current availability of application releases, they will come.
KDE 4.0 is only expected to be used by early adopters, not every KDE 3.5 user (and IMHO KDE 4.0 shouldn't be pushed onto other user types like planned for Kubuntu ShipIt (which by the way is said to have only 6 months support for its packages)).
KDE 4.1 development will not require the same amount of time as the big technology jump of KDE 4.0: expect KDE 4.1 later this year.
Last, again: KDE 4.0 is not KDE 4.

The eudev project launches

mbiebl — Thu, 20 Dec 2012 16:40:18 +0000

The xattr build issue is indeed a bug which has been fixed in [1]
Unfortunately this missed the v196 release.

[1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=cf...

The eudev project launches

hummassa — Thu, 20 Dec 2012 15:50:01 +0000

Not to worry about -- the poisonous atmosphere of this whole discussion and affair kind of warrants it.

The eudev project launches

daniels — Thu, 20 Dec 2012 15:01:18 +0000

> Forks in system components have a serious cost if they have ABIs or APIs on which a lot of things depend, and if those APIs diverge.

I agree, but I also define the ABI as pretty much the entire consumer-visible behaviour of the stack, rather than what's in a header file. Even if you do a straight like-for-like reimplementation, you're bound to end up with subtle differences in behaviour that will trip up unsuspecting users.

Hostility in plain sight

apoelstra — Thu, 20 Dec 2012 09:09:10 +0000

> 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

man_ls — Thu, 20 Dec 2012 08:53:18 +0000

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.

The eudev project launches

smurf — Thu, 20 Dec 2012 05:47:43 +0000

Since systemd will not work on BSD and Hurd kernels, there probability that somebody would try to force Debian to not support any other init systems is slim to nonexistent.

OTOH, a policy change which requires systemd support (there are, for instance, a few packages whose init scripts don't use the standard LSB functions) is something I'd appreciate.

The eudev project launches

nevets — Thu, 20 Dec 2012 04:14:05 +0000

> And you know if you then try to accommodate of making all these things optional and selectable specifically at configure time then you necessarily end up with a makefile where every second line is ifdef'ed in by a different configure switch, and even the .c sources are littered with #ifdef HAVE_xxx sections. And that is a) very hard to read and maintain, b) impossible to test in all combinations (explodes the test matrix...)

Maybe you should have a look at the Linux kernel. It's probably the most configurable project that ever existed. The kernel has matured where we don't have lots of #ifdef HAVE_xxx in the .c sources. We do put them into the .h files, where a static inline may act differently depending on the configs set. It's actually quite an elegant solution.

I based my Makefile for trace-cmd and kernelshark partially off of the Linux kbuild system. It's much more versatile and easier to understand than autoconf. I should work on making the kbuild system available for other projects as well. Package it up and reuse it.

Yes, we don't test all the different config options either, but you test what you ship. If someone finds a set of options that break, it's not that difficult (or time consuming) to fix it. I know this from experience as well.

I left off 'c)' because it was entirely an opinion, and not a technical issue at all.

The eudev project launches

hummassa — Thu, 20 Dec 2012 00:29:29 +0000

This is a real nice argument; except maybe for the part that you wouldn't be forced to think and make the patch nor maintaining it working (you could shift the responsability that half of the test matrix to the other, more interested, part). Your thing, when a patch like that comes, would be to overlook it, apply it, test *your* side of the test matrix and voilà.

> And yeah, I have no interest in maintaining such a beast, especially since it makes our life harder and gains us nothing.

This is the Most Honest part of your argument. "I am not in the mood, MY code (the code I have to look at from time to time) will get uglier, and it's mine, so I won't do it."

> Anyway, calling us pathetic, and five-year olds also doesn't really make use take you seriously.

Let's be honest here: I called BOTH sides of the discussion pathetic five-year olds; if you can't re-read this whole discussion, take a little distance and see how it is funny, I hate to tell you but you could use some sense of humour. I don't want to be taken seriously -- I want you (and by you, again, I mean both sides of this discussion) to perceive no one is really taking you seriously when you start bickering and sidetracking and trhowing tantrum fits. And this (bickering/sidetracking/tantrums, not being seen as serious) is a BIG loss to the Free Software Community as a whole; so you might want to consider that...

> Also, to clarify one thing: I don't really care whether somebody forks udev, quite frankly I am quite happy if they do so that they can deal with people like felipec, barbato or rulgard, and I don't have to. What I am annoyed about though is the FUD and falsehoods they spread while doing so. Most specifically their constantly repeated claim that udev upstream wouldn't allow non-initrd with /usr split off, even though we each time point out that udev doesn't care and it's other software that will break, not udev.

That is Ugly and Wrong. And that is the pathetic five-year olds part for the other side of the discussion.

Free Software does not need a REASON to be forked: the answer to "we have a team of developers and some infrastructure, we think we could do better maintaining this" is "Good! Be my guest! If it's copyleft, just distribute the source and all is well, maybe you will do a good job and I will use your commits here too!"

> But anyway, I'll leave it at this. It's unlikely I'll change you mind on things, and quite frankly you are not really succeeding to change mine either...

I never intended to change your mind. Even if I don't personally like systemd -- for the reasons I stated elsewhere in this thread, I admire your hard work and I am thankful for it. I just wished (before) that you were more accomodating, but you are not up to it, and there is nothing I can do about it. Now, eudev is a reality, and we all continue to win.

The eudev project launches

nix — Thu, 20 Dec 2012 00:09:24 +0000

And you know if you then try to accommodate of making all these things optional and selectable specifically at configure time

You mean like the helpers already were? I suppose that's been taken out now, too.

The eudev project launches

mezcalero — Wed, 19 Dec 2012 20:23:39 +0000

You know, what you are missing here is that people who go minimalist enough to only want udev from the systemd tree and nothing else, usually don't stop there and want even less than "all of udev" too. i.e. they want some of the helpers and not all, i.e. why would I need the accelerometer helper on my server or the MTD prober on my desktop?

Similar, some folks want only tmpfiles, or only detect-virt or some of the other stuff...

And you know if you then try to accommodate of making all these things optional and selectable specifically at configure time then you necessarily end up with a makefile where every second line is ifdef'ed in by a different configure switch, and even the .c sources are littered with #ifdef HAVE_xxx sections. And that is a) very hard to read and maintain, b) impossible to test in all combinations (explodes the test matrix...), and c) entirely unnecessary, as "make" is already good enough to allow people to build exactly what they need and what they don't want. And yeah, I have no interest in maintaining such a beast, especially since it makes our life harder and gains us nothing.

Anyway, calling us pathetic, and five-year olds also doesn't really make use take you seriously.

Also, to clarify one thing: I don't really care whether somebody forks udev, quite frankly I am quite happy if they do so that they can deal with people like felipec, barbato or rulgard, and I don't have to. What I am annoyed about though is the FUD and falsehoods they spread while doing so. Most specifically their constantly repeated claim that udev upstream wouldn't allow non-initrd with /usr split off, even though we each time point out that udev doesn't care and it's other software that will break, not udev.

But anyway, I'll leave it at this. It's unlikely I'll change you mind on things, and quite frankly you are not really succeeding to change mine either...

Lennart

The eudev project launches

andresfreund — Wed, 19 Dec 2012 20:04:18 +0000

I totally agree on this. As long as you do your part by far most of the kernel devs are *awesome* in fixing bugs. Up to giving you custom code that could possibly recover your lost data due to a fringe bug...

That attitude makes me hell of a lot more forgiving/accepting when facing problems or not totally thought through designs.

Hostility in plain sight

HelloWorld — Wed, 19 Dec 2012 20:01:44 +0000

> 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.

The eudev project launches

nix — Wed, 19 Dec 2012 19:41:29 +0000

Quite. My pedantry is on a high-power kick today, I'm afraid!