Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
This looks like an interesting story.
Systemd incompatible with...
Posted Oct 4, 2012 1:14 UTC (Thu) by nix (subscriber, #2304)
I'm damn glad that Linus and Al appear to agree with the rest of us who value stability in re the ongoing udev trainwreck. I don't *want* a new init system, I don't want to have to make invasive changes to my system on every udev upgrade, I just want something that manages a hotplug /dev for simple cases like usb mass storage plugged in after boot, lets me customize it by adding symlinks, tweaking permissions and the like, and otherwise gets out of the way.
udev used to do this when gregkh maintained it and for a while after, but currently is so far from this that is just not true. The last udev release that added a feature that I actually valued was about 130, but since then almost every release has been terrifying and introduced heaps of incompatible changes for no reason other than that it can, many releases have required invasive changes to the way my system is booted and break backward compatibility so that if I try to downgrade after a successful upgrade *that* will fail to boot, it's halfway to mandating systemd usage... no no no, bring back a udev with maintainership that understands how boot-critical software should be maintained, please. (That is to say, carefully and with great attention paid to backward compatibility and break-free upgrades without the poor distributors and/or upgraders having to whip themselves into a frenzy to do it.)
(Yes, I know I can just run an old udev. That's what I'm doing. But running unmaintained older versions of critical software required for boot because you can't trust the maintainers not to break your boot on every release is not good. Not good at all. Among other things, eventually programs will presumably start requiring a newer libudev...)
Posted Oct 4, 2012 9:46 UTC (Thu) by Eckhart (guest, #74500)
… except that it does not make sense to differentiate between "before boot" and "after boot" at all
Posted Oct 11, 2012 11:00 UTC (Thu) by nix (subscriber, #2304)
Just about the only hotplugged stuff is USB devices and the block devices that generally hang off them... and udev has worked perfectly well in *that* case for many years. So the cause of the continuing disruptive churn is completely opaque to me. It certainly doesn't benefit me one bit.
Posted Oct 11, 2012 14:20 UTC (Thu) by Jonno (subscriber, #49613)
The same goes for USB (of course) and SATA, and likely a host other systems...
As an anecdote, I had an oldish SATA device that suddenly stopped being bootable, but worked perfectly once booted from CD.
It turned out that the drive firmware had a boot time of O(n²) where n was the number of bad block relocations. Thus as the drive got old, it began to turn up after BIOS handed over to GRUB, and GRUB didn't have hot plug support :(.
I "solved" the problem by configuring BIOS to always do a full memory check at boot, slowing it down by 5-10 seconds, making booting work 9 cases out of 10. I have since replaced the disc, but it goes to showing that even devices you think are static aren't really...
Posted Oct 11, 2012 19:03 UTC (Thu) by nix (subscriber, #2304)
So any recomplication of the system to allow for those possibilities is wasted, from my perspective; and any administrative overhead imposed on me as a system administrator due to changes required by such recomplication is a cost sans benefit, that I would rather not pay.
Posted Oct 11, 2012 19:42 UTC (Thu) by raven667 (subscriber, #5198)
Posted Oct 11, 2012 19:55 UTC (Thu) by raven667 (subscriber, #5198)
Posted Oct 12, 2012 15:31 UTC (Fri) by nix (subscriber, #2304)
(Do laptops use PCIe yet? Presumably they do: it's got more power-saving features in it than PCI has.)
I don't actually object to the hotplug-everywhere world, as long as it doesn't break anything much it seems like it might add generality without cost. Unfortunately over the last forty or fifty udev releases (as measured by version numbers) this has not generally been true: every upgrade has, as mentioned elsewhere, been frightening and well above 50% would have broken booting if I hadn't done other things to prevent it. (Those breakages that were due to outright bugs in udev did get fixed fast, but most of them were due to explicit incompatibilities that required sysadmin action. And every one of those was a cost without a benefit. Classic example: udev 174, without advance warning or stated rationale of any kind, moved udevd from /sbin into /lib/udev without leaving behind a compatibility symlink, breaking booting uless you fixed your boot scripts. Because, you know, so many Unix daemons live in subdirectories of /lib or /usr/lib. Oh, wait, none whatsoever do, except for udev. Then udev 175 moved it again (into /usr/lib), and moved udevadm as well, breaking the boot *again* unless you compensated for it. The udev maintainers' motto appears to be "backward compatibility is for other people".)
Posted Oct 12, 2012 15:54 UTC (Fri) by raven667 (subscriber, #5198)
Oh I'm sure that all the internal busses are PCIe and if there is an external ExpressCard slot, that's hot-plug PCIe. When it comes to power management I imagine that some devices drop out and show up on the bus in a hot-plug fashion when they are powered off/on.
> moved udevd [...] without leaving behind a compatibility symlink, breaking booting ...
That's pretty screwed up in any event. I find the logic and evidence compelling for collapsing / into /usr but that is no excuse for not putting in appropriate compatibility measures, measures which should be totally straightforward and transparent.
> The udev maintainers' motto appears to be "backward compatibility is for other people"
That's an unfortunate motto of much (though thankfully not all!) of userspace, it's one area where having source available has lead people to believe that rebuilding and recompiling the world is acceptable so API/ABI compatibility don't matter.
Posted Oct 6, 2012 1:03 UTC (Sat) by jackb (subscriber, #41909)
I remember the transition from static device nodes to devfs because there were problems with static devices, then shortly afterwards we moved to udev because devfs was fatally, unfixably flawed, then devtmpfs + udev for some reason which isn't particularly clear, now there's a mention in LKML of moving udev into the kernel source tree.
Now wondering if we're ever going back to static device nodes, just to really come back full circle.
Posted Oct 6, 2012 1:08 UTC (Sat) by dlang (✭ supporter ✭, #313)
not everything is a laptop with random USB device of the day getting hot-plugged into it.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds