| |||||||||||||
Systemd incompatible with...Systemd incompatible with...Posted Oct 11, 2012 19:03 UTC (Thu) by nix (subscriber, #2304)In reply to: Systemd incompatible with... by Jonno Parent article: Quotes of the week
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.
(Log in to post comments)
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.
|
|||||||||||||