On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:My belief, and again I welcome concrete reasons why I'm not correct, is that adopting upstart poses a similar risk for the Hurd port as adopting systemd, and I care just as much about the Hurd port as kFreeBSD. And while kFreeBSD is in better shape due to the already-begun upstart port, there are still significant porting challenges in the way of maintaining feature parity in the kFreeBSD port at the level that it has today. Many of those challenges are going to remain regardless of which init system we pick.I haven't looked at this in much detail, and I suspect Dimitri hasn't yet although IIRC he did express some interest in doing so. But I haven't seen anyone else try to outline the scope of a port, so let me try to do so for the sake of general understanding. As far as I know, the hardest parts would be inotify, ptrace, and prctl (PR_SET_CHILD_SUBREAPER). inotify is used to notice changes to configuration files. This is certainly helpful for users, but it isn't critical as "initctl reload-configuration" works without it. We could probably do without this with the aid of a dpkg trigger.
ptrace is used for "expect fork" and "expect daemon"; as I indicated in another post, I think it would be preferable to avoid these in Debian and quite possibly to compile them out. (This would mean we wouldn't be able to translate Ubuntu jobs quite as directly, and a number of important jobs would definitely need to be changed, but the conversion isn't usually particularly difficult.)
prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification work properly when Upstart is supervising a user session. This isn't a required feature and could easily be compiled out until suitable kernel support is available (this actually seems like the sort of thing that could be done in the Hurd without too much difficulty, but I haven't looked into it). If absent, it might well impede the ability to do an advanced desktop port, but it wouldn't get in the way of porting the bulk of services.
There might also be odds and ends around the details of wait status handling.
So, I'll certainly concede that I haven't actually tried this, but from what I know of Upstart/libnih's system dependencies, I think that the Hurd could be accommodated with at worst possibly some loss of non-critical features.I want to mention again something that you'd dismissed as possibly a joke earlier, but which I was actually serious about: I think a world in which we use systemd on Linux and upstart on non-Linux ports, should upstart prove much more portable, actually makes sense. As I said in my other writeup, I believe the systemd feature advantage is sufficient to choose systemd in isolation, without the other issues discussed. I also believe that maintaining a systemd unit plus an upstart configuration is, modulo testing (which I realize is a huge issue), much easier than maintaining a single sysvinit script.I wouldn't discard this option out of hand, but I think it would need significant tool support to be practical (e.g. heuristic generation of Upstart job files from systemd units), unless we expect all service maintainers to have kFreeBSD/Hurd VMs lying around. Keeping the sysvinit scripts and using Upstart as the init daemon is another possibility, and at least in that case the sysvinit scripts are probably still lying around. We don't even necessarily have to choose between those up-front.