| |||||||||||||
Systemd incompatible with...Systemd incompatible with...Posted Oct 3, 2012 9:20 UTC (Wed) by gvy (guest, #11981)In reply to: Systemd incompatible with mounted /usr by mezcalero Parent article: Quotes of the week
Seems that the mantra has changed, and now Linux kernel is barely compatible with udev: https://lkml.org/lkml/2012/10/2/303
Lennart, would you please admit that being deaf to users is what hurted KDE4/GNOME3 efforts *big* time and stop advocating Kay no matter what? You're trying to break system layer which isn't easy enough to work around (like switching to XFCE or staying with WindowMaker).
I do understand that Red Hat might have some vision on future init but pushing the result down the throat won't help down the road.
Thank you for all the effort and good code, once upon a time many of your project were my favourite upstreams due to concise info and clean maintenance.
(Log in to post comments)
Systemd incompatible with... Posted Oct 4, 2012 0:33 UTC (Thu) by nix (subscriber, #2304) [Link]
Earlier link: <http://www.spinics.net/lists/netdev/msg185742.html>.
I boggle. Lots and lots of modules need firmware when they initialize. They always have, they always will. Decreeing that 'they should not' doesn't change the reality that they *do*.
Systemd incompatible with... Posted Oct 4, 2012 15:39 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
No, that's a sane requirement. Requesting firmware in module_init() can lead to deadlocks, if userspace can't process the request. It happened to work before because most of time userspace usually just reads firmware from a disk/initramfs.
So it makes sense to do something about it, however definitely not in the way udev developers do it.
Systemd incompatible with... Posted Oct 4, 2012 0:39 UTC (Thu) by bronson (subscriber, #4806) [Link]
Oof, I'm hoping Kay didn't actually release somewhat broken code without an idea of how he would fix it, but that seems to be what he's saying...?
This looks like an interesting story.
Systemd incompatible with... Posted Oct 4, 2012 1:14 UTC (Thu) by nix (subscriber, #2304) [Link]
So it appears.
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...)
Systemd incompatible with... Posted Oct 4, 2012 9:46 UTC (Thu) by Eckhart (guest, #74500) [Link]
> I just want something that manages a hotplug /dev for simple cases like usb mass storage plugged in after boot
… except that it does not make sense to differentiate between "before boot" and "after boot" at all
Systemd incompatible with... Posted Oct 11, 2012 11:00 UTC (Thu) by nix (subscriber, #2304) [Link]
Really? People keep saying this but I really don't think it's true. 90% of the devices on every system I own, including all the 'difficult' ones like the ones that are part of RAID arrays and the networking and the framebuffers and the like, are non-hot-pluggable or hotplugged so rarely that I don't care if I have to do something special to make the system pick them up (much less than once a year).
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.
Systemd incompatible with... Posted Oct 11, 2012 14:20 UTC (Thu) by Jonno (subscriber, #49613) [Link]
Technically all PCIe devices are "hot plugged", at some indeterminate period after it gets power, which it get simultaneously with the main system. If the main OS assumed that all PCIe devices was available at start, that would lead to all kinds of race condition.
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...
Systemd incompatible with... Posted Oct 11, 2012 19:03 UTC (Thu) by nix (subscriber, #2304) [Link]
See, there's a major difference between 'technically' and 'in practice' here. Maybe my PCIe and SATA buses are theoretically hotplugged, but not once in the entire history of any of my systems with any of these buses has any device ever appeared while the OS was running, nor has one ever gone away except on one occasion when a disk failed (so hardly a hotplug event). Nor have I ever heard of systems other than really really high-end boxes (that I could not possibly afford) that can hotplug PCIe (though I have seen machines with external SATA connectors -- always unoccupied in my experience, but possibly useful in emergencies or to connect external drive enclosures, I suppose).
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.
Systemd incompatible with... Posted Oct 11, 2012 19:42 UTC (Thu) by raven667 (subscriber, #5198) [Link]
Maybe I just don't understand but doesn't the fact that these busses are possible to hot-plug and the fact that when it comes to enumeration and probing they behave like hot-plug in that they show up on the bus whenever they become ready mean that the driver systems that handle these devices have to handle the hot-plug case. The infrastructure has to be there to support it so I don't see how you can get rid of the complexity of dealing with these devices as hot-pluggable. It seems a simplification to just handle everything as a hot-plug case, rather than trying to maintain separate static and hot device initialization. infrastructure
Systemd incompatible with... Posted Oct 11, 2012 19:55 UTC (Thu) by raven667 (subscriber, #5198) [Link]
That was kind of a crappy comment. Maybe it would be better to say that "in practice" the hardware treats power-on enumeration like a series of hot-plug events which is why it makes sense for the kernel to handle it that way too. "in theory" maybe you could close your eyes and treat the system as static but there would be cases where that would cause you to get wedged that hot-plug wouldn't.
Systemd incompatible with... Posted Oct 12, 2012 15:31 UTC (Fri) by nix (subscriber, #2304) [Link]
I suppose that's true, if it is common to have PCIe devices that take so long to come up that they haven't started by the time POST has finished. That's not true of any system I own, but since all my systems are desktops and desktops are famously slow to POST...
(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".)
Systemd incompatible with... Posted Oct 12, 2012 15:54 UTC (Fri) by raven667 (subscriber, #5198) [Link]
> (Do laptops use PCIe yet? Presumably they do: it's got more power-saving features in it than PCI has.)
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.
Systemd incompatible with... Posted Oct 6, 2012 1:03 UTC (Sat) by jackb (subscriber, #41909) [Link] 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.
Systemd incompatible with... Posted Oct 6, 2012 1:08 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
many people never stopped using static device nodes. For systems that don't have the hardware changing on them, a static /dev works very well.
not everything is a laptop with random USB device of the day getting hot-plugged into it.
|
|||||||||||||